What is Feature Store?

The problem it exists to solve

Consider a feature like 'customer's average order value over the last 30 days'. In training, it is computed in SQL over a warehouse. In production, it must be computed in application code within a few milliseconds. Two implementations, written by different people at different times, of the same idea.

They diverge. One counts cancelled orders, the other does not. One uses calendar days, the other rolling 720 hours. The model was trained on one definition and is served the other, so accuracy quietly degrades with no error anywhere. This is training-serving skew, and it is among the most common and hardest-to-diagnose production failures in machine learning.

What it provides

One definition, two paths. A feature is defined once and served both as a historical batch for training and as a low-latency lookup for inference. This is the core value; everything else is secondary.

Point-in-time correctness. The subtle and important part. To build a training row for an event on 3 March, every feature must reflect what was known on 3 March — not today's value. Naively joining current aggregates onto historical events leaks the future into training, and produces a model that validates beautifully and fails in production. Doing these 'as-of' joins correctly by hand is genuinely difficult, and getting it for free is often the strongest argument for adopting a store.

Reuse and discovery. Features become shared assets across models rather than being re-derived in every project, with lineage and ownership attached.

Architecturally this is usually an offline store (a warehouse holding full history) plus an online store (a low-latency key-value store holding current values), fed by shared transformation definitions.

When it is overkill

Feature stores add real complexity: another system to operate, another failure mode, and a materialisation pipeline to keep healthy. For a single model with features computed in one place, they are not worth it.

The signals that you have outgrown doing without one: several models sharing features, features that are expensive to compute and recomputed redundantly, a training-serving skew incident that has already cost you, or a need for real-time features where the online lookup path genuinely differs from batch.

If none of those apply, you can capture most of the benefit far more cheaply. Define feature transformations in a single shared library imported by both the training pipeline and the serving code, and write tests asserting the two produce identical output on fixed inputs. That eliminates skew — the main risk — without adopting a platform. Add the platform when the number of models, not the ambition of one, makes the coordination cost real. This is the same sequencing point made in MLOps: practice before platform.