Feature Store
A feature store is the shared layer that computes, stores, and serves machine-learning features consistently to both training and inference.
Definition
A feature store is a data system that turns raw events into named, versioned, point-in-time-correct features and serves them to two consumers: offline pipelines that build training sets and online services that answer prediction requests with single-digit-millisecond latency. Its defining promise is train-serve consistency: the same transformation definition backs both paths, so a model never sees feature semantics at training time that differ from production.
Context and scope
Adopted by teams running more than a handful of models, where duplicated feature logic, label leakage, and training-serving skew have already caused silent accuracy loss in production.
Common misconceptions
- A feature store is just a fast key-value cache — the cache is only the online serving tier; point-in-time correctness and offline reproducibility are the harder halves
- It removes the need for data engineering — someone must still define, monitor, and backfill each feature; the store enforces discipline rather than creating it
- Offline and online values must always be byte-identical — small numeric drift is tolerated if the transformation lineage and refresh window are explicit
Anti-patterns
- Computing features inside the model training script so the online service re-implements them differently
- Storing raw aggregates without point-in-time joins, leaking future labels into historical training rows
- Serving features with no freshness metadata, so stale values are indistinguishable from current ones
Related concepts
Authoritative source
What it is
A feature store separates a feature definition from its storage and serving. Each feature is a named, owned, documented transformation whose outputs are materialised twice: into a columnar offline store for historical windows and into a low-latency online store for the latest value. A registry holds the definitions, owners, and data-quality expectations, making features discoverable and reusable instead of copy-pasted per model.
Why it matters
Without a shared store, the same quantity — a rolling session length, a fraud-velocity counter — gets re-implemented once in SQL for training and once in service code for inference. The two drift, the model silently degrades, and nobody can explain why offline metrics and production behave differently. A store makes train-serve skew a configuration bug rather than a mystery.
How teams use it
Pipelines write streams and batches into the offline store; an ingestion job materialises the newest values into the online store on the same schedule. Training does point-in-time joins so each label sees only features available at that timestamp. Serving reads by entity key. Governance features such as feature-level SLAs, lineage, and deprecation keep the catalogue trustworthy as it grows.