Feature stores: do you actually need one?
A feature store solves a real problem that most teams do not yet have. How to tell whether you are one of them.
Feature stores are frequently adopted as a sign of maturity rather than as a solution to a problem the team currently has. They are excellent infrastructure for a specific situation.
The problem they solve
Training-serving skew — the same feature computed differently in the batch pipeline and the live request path — plus duplicated feature logic across teams. If neither is happening to you, a feature store is overhead.
Feature store, or a shared library?
- One model, one teamShared feature library
- Several models sharing featuresShared library, then reassess
- Live inference over historical windowsFeature store
- Production accuracy below offline evaluationYou have skew — fix that first
- Can't reconstruct a past feature valueFeature store, for point-in-time correctness
Signals you have the problem
It is usually obvious in hindsight and easy to miss in the moment:
- Several models consuming the same underlying features
- Multiple teams reimplementing the same business definitions
- Live inference needing features computed over historical windows
- Production accuracy consistently below offline evaluation
- Nobody able to answer what a feature's value was at a past point in time
What to do first instead
A shared feature library — one repository, one definition per feature, imported by both the training pipeline and the serving code — removes most of the skew risk for a fraction of the operational cost. Reach for the platform when the library stops being enough.
Point-in-time correctness is the feature that matters
A store earns its place when
- It can reconstruct a feature's value at a past moment
- Training and serving read the same definition
- Several teams consume the same features
- Live inference needs historical windows
Warning signs
- Offline metrics far better than production
- Nobody can say what a feature was worth last March
- Feature logic copy-pasted between repositories
- Adopted because it signals maturity
If you do adopt one
Point-in-time correctness is the feature that matters. A store that cannot reconstruct exactly what a feature's value was at the moment of a historical event will let leakage into your training data, which produces excellent offline metrics and a disappointing product.