Feature Stores Explained: When Do You Actually Need One?
Last updated:
The problem a feature store solves
Models do not eat raw data. They eat features: 'orders in the last 90 days', 'days since last login', 'average basket value this quarter'. Somebody writes the code to calculate those, usually in a notebook, when the model is first trained.
Then the model goes live, and a developer writes the same calculation again inside the application, in a different language, against a different database. The two versions drift. Maybe one counts cancelled orders and the other does not. The model's accuracy quietly drops and nobody can explain why.
That mismatch has a name, training-serving skew, and preventing it is the main reason feature stores exist. The second reason is reuse: once three models all need 'customer lifetime value', calculating it three different ways is asking for trouble.
What a feature store actually is
Strip away the vendor diagrams and a feature store is three things working together.
- An offline store. Historical feature values, kept with timestamps, so you can build training data showing exactly what was known on any past date.
- An online store. The latest feature values held in a fast database, so a live application can fetch them in milliseconds.
- A registry. A catalogue saying what each feature means, how it is calculated, who owns it and which models use it.
The calculation is defined once and feeds both stores. That single definition is the whole point. Everything else is plumbing.
Signs you genuinely need one
- You run, or are about to run, several models that share inputs about the same customers, products or transactions
- At least one model makes predictions in real time, inside a checkout, an app or an API call, and needs up-to-the-minute values
- You have already been caught out by training and live calculations disagreeing
- More than one team or contractor builds models and keeps reinventing the same features
- You need to prove, for audit or regulatory reasons, exactly what data a model saw when it made a decision
If three or more of those describe you, a feature store is worth a serious look. If none do, it is almost certainly premature.
Why most smaller businesses do not need one yet
A typical SME machine learning setup is one or two models, scored overnight in a batch, writing results back to a CRM or a dashboard. For that, a feature store adds a new system to run, secure and pay for, while solving a problem you do not have.
The same benefits can be had more cheaply. Define features as SQL tables or views in your warehouse or PostgreSQL database, managed with a tool such as dbt so every calculation is versioned. Have both the training job and the scoring job read from those tables. Keep a dated snapshot each night so you can reconstruct history. That is, functionally, a small offline feature store without the name.
Most feature store problems in small teams are really discipline problems. One place where calculations live solves most of them.
The options, from simplest to heaviest
| Approach | Good fit | Effort and cost |
|---|---|---|
| Feature tables in your existing database or warehouse | One to three batch models, a small team | Low; uses tools you already run |
| Shared Python feature library plus nightly snapshots | Models built by developers who prefer code to SQL | Low to moderate; needs code review discipline |
| Open-source feature store such as Feast | Mixed batch and real-time models, an in-house engineer to run it | Moderate; you operate it yourself |
| Feature store built into a cloud ML platform | You already run on Databricks, SageMaker, Vertex AI or similar | Moderate to high; convenient but ties you to the platform |
Moving up the table should be a response to pain you are actually feeling, not something done in anticipation. The step from well-organised tables to Feast is not dramatic when the time comes, because the feature definitions already exist.
What goes wrong with feature stores
The failures we see are organisational rather than technical. A feature store gets installed, a handful of features are added during the initial project, and then new models are built in notebooks that ignore it because it is quicker. A year later it is an expensive, half-populated database.
The other common problem is point-in-time correctness. Building training data means joining each historical event to the feature values that existed at that moment, not the values today. Get this wrong and you create data leakage, where the model learns from information from the future. We explain that trap in data leakage: the silent bug that makes models look brilliant.
How we would introduce one
At SpiderHunts, when a client's machine learning estate is growing, we start by moving existing feature calculations into one versioned place and making both training and scoring read from it. That alone removes most skew. Only when a real-time model arrives, or the number of models makes reuse painful, do we add an online store and a registry.
The feature tables also depend on the pipelines feeding them, which we cover in data pipelines that keep machine learning models fed. If your data does not yet live somewhere central, it may be worth reading do you need a data warehouse first. And if you want a second opinion on your setup, that is part of what our machine learning service covers.
Frequently asked questions
What is a feature store in machine learning?
Is a feature store the same as a data warehouse?
Do I need a feature store for batch predictions?
What is training-serving skew?
Is Feast a good choice for a small company?
Wondering if your ML setup needs more structure?
Tell us how many models you run and how they get their data. We will tell you whether a feature store would help or just add another system to look after.