What Is a Feature Store? ML Feature Management Explained

A feature store is a system that centralizes how machine learning features — the derived inputs a model actually trains and predicts on — are computed, stored, and served, so the same feature definitions and values are used consistently across training and production. Without one, teams tend to reimplement the same feature logic twice: once in a data pipeline for training, and again in application code for real-time inference, with no guarantee the two stay in sync.

The problem it solves: training-serving skew

A “feature” in machine learning is rarely a raw database column. It’s usually a derived value: a user’s average order value over the last 30 days, a rolling click-through rate, a ratio between two columns, an embedding computed from raw text. Computing that feature correctly requires the same logic wherever it’s used — but training pipelines and production serving systems are often built by different teams, on different infrastructure, at different times.

Training-serving skew is what happens when those two computations drift apart: the training pipeline computes “30-day average order value” one way, batch and offline, while the production API computes something subtly different — a different time window, a different null-handling rule, a bug introduced in a rewrite — when serving real-time predictions. The model was trained on one distribution of values and evaluated in production on a slightly different one, and the gap is often invisible until model performance quietly degrades in ways that are hard to trace back to a root cause.

A feature store exists specifically to close that gap: one definition of each feature, computed once, consumed by both training and serving paths.

The two halves: offline and online stores

Feature stores typically split storage into two paths with different performance requirements:

• Offline store. Holds historical feature values at scale, usually backed by a data warehouse or data lake, sometimes structured as a data lakehouse. This is what training pipelines read from — pulling large batches of historical feature values, often with point-in-time correctness so a model trained on data from six months ago only sees feature values as they existed at that time, not values computed with the benefit of hindsight.
• Online store. Holds the current value of each feature, optimized for low-latency lookups — often backed by a key-value store like Redis. This is what a production inference API queries at request time: given a user ID, fetch that user’s current feature vector in milliseconds, then feed it to the model.

The feature store’s job is keeping these two in sync: the same transformation logic that populated a feature’s history in the offline store is what continuously updates its current value in the online store, whether through a batch or streaming pipeline.

How feature pipelines fit with ETL/ELT

Getting raw data into feature form is itself a data engineering problem, and feature stores sit downstream of the same ETL/ELT pipelines that populate a warehouse for other purposes. What a feature store adds on top isn’t the transformation itself — it’s a registry: a catalog of feature definitions, their computation logic, their freshness guarantees, and which models depend on them, so a feature can be reused across projects instead of being redefined ad hoc in every model’s training script.

That reuse is a large part of the practical value. Without a shared registry, ten teams solving loosely related prediction problems on the same underlying data end up writing ten slightly different implementations of “user tenure” or “recent activity,” each with its own bugs and its own drift from what production actually serves.

Feature stores vs vector databases

It’s worth distinguishing a feature store from a vector database, since both sit in ML infrastructure and both serve values at low latency. A vector database stores and searches embeddings — dense representations used for similarity search, commonly in retrieval-augmented generation pipelines. A feature store stores structured, often tabular features — numbers, categories, aggregates — used as direct model inputs, and cares as much about historical, point-in-time correctness for training as it does about serving speed. The two are complementary rather than substitutes: a recommendation system might pull a user’s structured features from a feature store and a candidate item’s embedding from a vector database in the same request.

Where it fits relative to fine-tuning and evals

Feature stores are infrastructure for traditional predictive ML — classification, regression, ranking, recommendation — more than for large language model workflows, where the analogous consistency problems show up differently: fine-tuning and in-context learning both depend on training and inference-time context matching, and LLM evals exist partly to catch the same kind of quiet drift between what a model was tuned on and what it sees in production. The underlying discipline — make sure training-time and serving-time inputs actually match — is the same idea wearing a different name depending on which corner of ML you’re standing in.

When it’s worth adopting

A feature store earns its complexity once an organization has enough models, teams, and reused features that inconsistency between training and serving becomes a recurring, hard-to-debug problem — not before. A single team training and serving one model with a straightforward feature pipeline usually doesn’t need one; the overhead of running and maintaining a dedicated feature store outweighs the drift risk at that scale. It becomes worth it when multiple models and teams share overlapping features, when real-time serving latency matters, and when point-in-time-correct historical data for training is hard to get right by hand.

The takeaway

A feature store’s core job is making sure a machine learning model sees the same feature values, computed the same way, whether it’s being trained on historical data or serving a live prediction. That consistency — closing the gap between offline training pipelines and online serving paths — is what prevents the quiet, hard-to-diagnose performance degradation that comes from training-serving skew, and it’s the main reason feature stores exist as a distinct piece of ML infrastructure rather than just another data pipeline.