Feature store: when it's worth it

Feature stores emerged as a pattern everyone started wanting to build: a centralized repository where features get computed once and then served to both training pipelines and real-time inference services, guaranteeing consistency.

For a single team with one or two models, a well-tested transformations repository in Git does the same job well enough. You version it. You test it. You deploy it. Feature store infrastructure adds complexity and operational overhead you do not need.

The real problem they solve is training-serving skew: when the model learns from one version of a feature and inference gets a different version. That is a silent, expensive failure that causes problems in production.

It happens because training uses historical data computed one way, and inference uses current data computed slightly differently. Small drifts in the logic, different libraries, rounding differences. The model learns something that inference never provides.

Before recommending a feature store, we compare the feature computation in training against what would run in production on the same date. If they diverge, the business case is already written. If they match, you do not need it yet.

We built one for a client with four teams and fifteen models in production. The divergence was real and expensive. Before that threshold, every team was better served by discipline in a shared repository.