Feature Store

A feature store is a centralised platform for defining, computing, storing, and serving machine-learning features consistently across training and inference. The canonical problems it solves: training-serving skew (feature computed one way during training, another way at serving time), feature reuse across models and teams (the same customer-lifetime-value feature shouldn't be reinvented in five places), point-in-time correctness (when training, see only feature values that were actually available at that historical timestamp, not leak-through from the future), and low-latency online serving. A full-featured store has an offline store (historical feature values for training), an online store (latest feature values for low-latency inference), a feature registry, and a transformation layer that keeps both stores consistent.

The 2026 landscape split into three tiers. **Feast** is the dominant open-source option — Python-native, sits on top of existing infrastructure (Redis/DynamoDB online, BigQuery/Snowflake offline), integration-heavy but flexible. **Tecton** is the managed SaaS leader for teams that want a batteries-included feature platform without the MLOps overhead. **Databricks Feature Store** and **Vertex AI Feature Store** and **SageMaker Feature Store** are the cloud-native options bundled with their ML platforms. Smaller players (Hopsworks, Iguazio, Chalk) compete in vertical niches. Feature-view abstractions (feature is a derived column with point-in-time semantics) have become standardised across products.

For APAC mid-market teams, the practical guidance is **most teams do not need a feature store yet**. If you run fewer than 10 production models, most features are reused in at most 1-2 places, and your teams are small enough that training-serving skew is unlikely to go undetected, batch pipelines plus notebooks handle feature work adequately. Adopt a feature store when the team exceeds ~4 ML engineers, models share features routinely, and online low-latency serving becomes a requirement. Premature feature-store adoption adds significant MLOps overhead with little return.

The non-obvious failure mode is **training-serving skew**. The feature is defined in a Spark batch job at training time (with a specific null-handling convention, rounding, and time-window semantics) and in a streaming job at serving time (with different defaults, a subtly different time window, and no awareness that offline used a forward-fill). The model trains cleanly, passes evaluation, and degrades silently in production because online features don't match offline. A feature store that enforces one definition compiled into both paths prevents this; a feature store where definitions diverge between offline and online (because engineers can edit each path independently) reproduces it. Governance over feature definitions is the core value.