Stop 17 · MLOps & Model DeploymentTopics · 10/10

Feature Stores (Overview)

In short

Training used 'orders in the last 7 days' computed one way. Serving computed it slightly differently. The model quietly gets worse. Feature stores exist to stop exactly this.

Centralized systems for storing, sharing and serving ML features consistently between training and inference — solves the common bug where training and serving features silently drift apart.

The blob opens a round steel spice box with small bowls of colourful spices while two cooks reach in.

Think of it like this

One shared masala dabba

If every cook in a dhaba grinds their own garam masala, the dal tastes different on every shift. So the head cook makes one batch and everyone uses the same dabba. A feature store is that shared dabba: features computed once, used the same way for training and serving.

Watch it happen

Same features for training and serving

Feature job

Offline store

Online store

Model API

write orders_7d history

1/5A scheduled job computes features from raw data and saves the full history for training.

The big ideas

What you need to know

One definition

Each feature is defined once in code. Training and serving both read from it.

Offline store

Holds history for building training sets. Usually a warehouse or files.

Online store

Holds the latest value per entity for fast lookups, often in a key-value database like Redis.

Point-in-time correct

Training rows only see feature values from before the label happened. This prevents subtle data leakage.

See it in code

Walk through the code

python

1from feast import FeatureStore2 3store = FeatureStore(repo_path=".")4 5features = store.get_online_features(6    features=[7        "user_stats:orders_last_7d",8        "user_stats:avg_order_value",9    ],10    entity_rows=[{"user_id": 1042}],11).to_dict()12 13print(features)

1/3Point at a Feast repo that defines your features.

Reading online features with Feast, an open-source feature store. Training uses get_historical_features with the same names.

Save yourself the pain

Common mistakes

Oops

Rewriting feature logic in the API because 'it's just a quick sum'.

Do this instead

Two copies of logic drift apart. Compute once and read the stored value in both places.

Oops

Adding a feature store to a two-feature student project.

Do this instead

It's worth it with many features, models and teams. For small projects, a shared Python function is enough.

Your mission

Try Feast locally

~40 min

Quick check

What problem does a feature store mainly solve?

Go deeper

1Read how a feature store keeps offline (training) and online (serving) features consistent.
2Understand the 'training-serving skew' problem a feature store is designed to prevent.
3Explore an open-source feature store (e.g. Feast) at a conceptual level.