Concept
Feature Store
A centralised data layer that stores, manages, and serves the computed features that ML models use for both training and inference - eliminating the costly problem of different teams recomputing the same features differently.
Added May 18, 2026
In most ML systems, the gap between raw data and model input is substantial. Raw data - user events, transaction records, sensor readings - must be processed into features: aggregated statistics, normalised values, embeddings, interaction counts. This feature engineering is expensive to compute, requires domain expertise, and is commonly duplicated: one team computes "user's average purchase value in the last 30 days" for a recommendation model, another computes it independently for a risk model, and the results differ because of subtle implementation differences.
A feature store solves this by centralising feature definitions, computation pipelines, and storage. Features are defined once by feature engineering teams, computed on a schedule, and stored in the feature store. Any model - recommendation, risk, personalisation, fraud detection - retrieves the same feature values rather than each team recomputing them independently.
Feature stores have two serving layers that reflect ML's offline/online dichotomy. The offline store (typically a data warehouse like BigQuery or Redshift, or a lakehouse) provides historical feature values for model training. When training a model, you retrieve the historical values of your features as of any past timestamp - this is point-in-time correct retrieval, which prevents training-serving skew by ensuring you only use features that would have been available at the moment the label was generated. The online store (typically a low-latency key-value store like Redis or DynamoDB) provides current feature values for real-time model inference, where millisecond latency is required.
Training-serving skew - where the features computed during training differ from those computed during inference - is one of the most common and costly ML bugs. A feature store addresses this directly: the same feature definition generates values for both training data and live inference, so the model always sees the same distribution at serving time as it saw during training.
Mature feature store implementations (Feast, Tecton, Hopsworks, managed offerings in cloud ML platforms) add monitoring for feature drift, feature discovery interfaces so teams can find and reuse existing features, and versioning so feature definitions can change without breaking downstream models.
For large organisations, a feature store can provide significant cost savings - expensive feature computations like embedding generation or complex aggregations are computed once and shared rather than independently replicated by each model team.
Analogy
A shared ingredient prep station in a large professional kitchen. Rather than each chef independently peeling and chopping vegetables for their dish, a prep team cleans, cuts, and stores standard ingredients that all chefs draw from. Every dish uses the same consistently prepared base ingredients. The feature store does the same for ML: feature engineering teams prepare and store standard feature computations that all model teams share, ensuring consistency and eliminating duplicated work.
Real-world example
A fintech company has ten different ML models that all need to know a user's 30-day transaction statistics. Without a feature store, each model team implements the computation independently - slightly differently, against slightly different data snapshots - leading to subtle inconsistencies and duplicated infrastructure costs. With a feature store, the feature is defined once, computed on a daily schedule, and any model team retrieves it via a simple API call. Training and serving both use the same feature store, guaranteeing consistency.
Why it matters
Feature stores address training-serving skew, eliminate duplicated feature engineering work, and enable feature reuse across teams. For large ML organisations, they reduce both engineering cost and model reliability problems caused by inconsistent feature computation. Understanding feature stores explains a key challenge in productionising ML that is often glossed over in academic discussions but looms large in any real deployment.
In the news
No recent coverage - check back later.
Related concepts