Feature Stores: One Source of Truth for Features

The problem they solve

A feature like user_avg_basket_30d is computed:

• in training, by a batch SQL job over Parquet,
• in serving, by a Python function over Redis.

If those two implementations drift by even a small amount, you have training-serving skew — the model behaves differently in production than in evaluation, often silently. The accuracy gap doesn't show up in your test set.

A feature store (Feast, Tecton, Vertex Feature Store, SageMaker Feature Store, Databricks UC) imposes:

1. Single definition of each feature (a FeatureView).
2. Dual storage — offline (for training joins) and online (low-latency for serving).
3. Point-in-time joins so training samples never use the future.
4. Versioning + lineage for the features themselves.

Imagine a central spice rack in a restaurant chain. Every kitchen pulls 'cumin' from the same labelled jar, refilled from the same supplier. Without it, the New York branch uses ground coriander labelled 'cumin' and the dish tastes wrong — but nobody can explain why.