Feature Store

A feature store is a system that sits between raw data and machine-learning models, holding the engineered inputs — the features — that models actually consume. A feature is a single measurable signal: a customer's number of orders in the last thirty days, the average basket value, days since last visit. Building these once and scattering the code across notebooks and services is how teams end up with subtly different versions of 'orders in the last thirty days.' A feature store centralizes the definition, computes the value, stores it, and serves it on request. It typically has two faces: an offline store holding historical values for training models, and an online store serving the latest values with low latency when a model makes a live prediction. The point is one definition, consistently applied everywhere.

The problem a feature store solves is consistency across time and place. A model is trained on historical feature values, then deployed to score new events in production, and if the feature is computed even slightly differently in those two settings, the model's live behavior drifts from what training promised — a failure known as training-serving skew. A feature store fixes this by computing each feature from one definition and serving it to both training and inference, so the number the model learned from is the number it sees in production. It also lets teams share features: a 'customer lifetime spend' feature built by one team can be reused by another instead of rebuilt, which saves work and prevents divergent copies. Governance, versioning, and monitoring of features usually live here too.

A feature store is easy to confuse with the broader data platforms it draws from, but its job is narrower and more specialized. A data lake stores raw data of every kind cheaply, with structure applied only when something reads it; a data warehouse stores cleaned, structured data organized for analytics and reporting. Both are general-purpose stores of data. A feature store is purpose-built for one thing: serving model-ready features for machine learning. It usually pulls from a lake or warehouse, transforms that data into features, and then does what neither of them does well — serves those features online, at low latency, with the exact same definition used in training. So the lake and warehouse are where data lives broadly, and the feature store is where ML features are defined, stored, and served.

The distinction matters because a warehouse alone cannot guarantee the two things a feature store exists to provide: online serving fast enough for live inference, and a single feature definition shared between offline training and online scoring. You can compute features in a warehouse for training, but reproducing those exact computations in a real-time service is where skew creeps in. A feature store closes that gap by owning the feature layer specifically. It is not a replacement for the lake or warehouse — it complements them, sitting on top and specializing in features. Smaller teams with simple, batch-only models may not need one; the value shows up when many models, many features, and low-latency serving make consistency and reuse genuinely hard to maintain by hand.

Using a feature store well means treating feature definitions as shared, versioned assets rather than throwaway code. Define each feature once, document what it means and how it is computed, and let both training and serving read from that single definition so the values match. Use the offline store to assemble training sets with point-in-time correctness — features as they were at the moment of each historical event, not as they are today, which quietly leaks the future into training if you are careless. Use the online store for low-latency serving, and monitor features in production for drift, staleness, and missing values. Reuse existing features before building new ones, so the organization accumulates a trustworthy library instead of a pile of near-duplicates.

The failures are predictable. Teams introduce training-serving skew by computing a feature one way for training and another for inference — the exact problem the store is meant to prevent. They leak future information by joining features without point-in-time correctness, producing models that look brilliant offline and disappoint in production. They let the online store go stale, serving yesterday's values to today's predictions. And they over-engineer, standing up a heavy feature platform for a couple of batch models that never needed one. The discipline is to adopt a feature store when consistency, reuse, and low-latency serving are real problems, define features once, enforce point-in-time correctness, and monitor what production actually serves — so the model sees in the wild exactly what it learned in training.

The feature store emerged in machine-learning engineering practice in the late 2010s as teams sought one place to define, store, and serve the features that models consume.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where feature store is a core concern: