A feature store is infrastructure that computes, stores, and serves the input features a machine learning model needs — with one specific job: making sure the feature values a model trained on are computed the exact same way as the feature values it sees at inference time. When those two computations drift apart even slightly, a model sees different-shaped input in production than it learned on, and that mismatch — training-serving skew — is one of the most common, hardest-to-diagnose causes of a model quietly getting worse after launch. A feature store fixes it by defining each feature once and generating both the batch and real-time computation paths from that single definition.
How it works
Every feature store splits into two halves that serve different access patterns. The offline store holds historical feature values at scale, optimized for the bulk reads a training job needs — usually backed by the same data lake or warehouse already powering other analytics. The online store holds only the current value of each feature, optimized for the millisecond-level lookups a live prediction request needs — usually a key-value store or in-memory cache. A feature registry sits on top of both, holding the actual definition of each feature (the transformation logic, not just the value) so both stores stay derived from one source of truth instead of two hand-maintained implementations.
# Feast: define a feature once, read it from either store
from feast import FeatureStore
store = FeatureStore(repo_path=".")
# Training: bulk historical read from the offline store
training_df = store.get_historical_features(
entity_df=entity_df,
features=["user_features:avg_order_value_30d"],
).to_df()
# Serving: millisecond read from the online store
features = store.get_online_features(
features=["user_features:avg_order_value_30d"],
entity_rows=[{"user_id": 42}],
).to_dict()
The critical detail is that avg_order_value_30d is defined once, and both calls resolve to the same underlying transformation — the training job and the live request are never at risk of computing it two different ways in two different codebases.
Feature store landscape
| Platform |
Model |
Notable strength |
Tradeoff |
| Feast |
Open source, self-hosted |
No vendor lock-in, wide backend support |
You operate and integrate it yourself |
| Tecton |
Managed |
Strong streaming feature support, mature point-in-time joins |
Commercial cost, less relevant below multi-model scale |
| Databricks Feature Store |
Managed, integrated with Databricks |
Tight integration if already on Databricks/Delta Lake |
Less useful outside the Databricks ecosystem |
| Vertex AI Feature Store |
Managed, GCP-native |
Simple if fully on Google Cloud and Vertex AI |
Less flexible outside GCP |
| SageMaker Feature Store |
Managed, AWS-native |
Simple if fully on AWS and SageMaker |
Less flexible outside AWS |
| Shared feature library (no platform) |
Hand-rolled |
Cheapest, simplest for a single model |
No online/offline separation or registry; you own consistency by discipline |
Most teams below a handful of production models are better served by the last row — a well-tested, shared feature computation library — than by adopting a dedicated platform whose operational cost only pays off once several models and teams share overlapping features.
Point-in-time correctness
The subtler problem a feature store has to get right is data leakage through time. If a training example dated in March is joined against the current value of a feature instead of what that feature's value was in March, the model trains on information it would never have had at real prediction time, producing offline metrics that look strong and then collapse in production. Correct point-in-time joins are what separate a real feature store from a plain table of precomputed values, and they are the part worth testing hardest before trusting a platform's output.
Common mistakes
- Adopting a feature store before there is real feature-sharing pain. One model with a simple, well-tested pipeline rarely needs the online/offline split and registry overhead a platform adds.
- Trusting a platform's point-in-time joins without verifying them. Run a manual spot check against known historical values before assuming the join logic is leak-free.
- Skipping ownership and naming conventions in the registry. Without them, teams redefine the same feature slightly differently under different names, recreating the exact inconsistency the store was supposed to prevent.
- Forgetting online store latency budgets. A feature that takes 200ms to look up defeats the purpose if the serving path has a 50ms total budget; benchmark the online store under realistic load, not just correctness.
FAQ
Do I need a feature store for a single model?
Usually not. A single model with one well-tested pipeline rarely justifies the operational cost; the value shows up once multiple models or teams share overlapping features.
Is Feast a full replacement for a managed platform?
For teams willing to operate it themselves, yes for most core functionality. Managed platforms typically add stronger streaming support, more polished tooling, and less operational burden, at a commercial cost.
How is a feature store different from a data warehouse?
A warehouse serves general analytics queries. A feature store adds a low-latency online serving path and a registry of feature definitions purpose-built for ML, which a warehouse alone does not provide.
What is the biggest risk in building one in-house?
Getting point-in-time correctness wrong. It is easy to build something that looks correct in testing but leaks future information into training data in subtle ways that only show up as unexplained production underperformance.
Where to go next
See LLMOps explained and model serving infrastructure for what happens after features feed a model, and data lake vs data warehouse for the storage layer most offline feature stores are built on.