Feature store

What is a feature store?

A feature store is a governed place to define, store, share, and serve machine-learning features. Features are the derived variables a model uses as input: average order value in the last 30 days, number of failed logins this week, customer tenure, distance to the nearest branch, or a product's rolling return rate.

The feature is not usually the raw data. It is the calculated signal produced from raw data. A feature store makes those signals reusable and consistent.

Without a feature store, each data scientist may build the same feature in a notebook with a slightly different formula. The model trains on one version, production serves another, and performance drops in a way that is hard to explain. That gap is called training-serving skew.

What problem does it solve?

Training-serving consistency
The feature definition used during training should be the same one used during inference. If a fraud model trained on a 30-day transaction count, production should calculate that count the same way.

Reuse
A good customer-activity feature can help churn, fraud, recommendation, and segmentation models. Build it once, test it, document it, and let teams reuse it.

Point-in-time correctness
When building historical training data, you need the feature value as it was at the time of the label, not the value as it is today. Otherwise the model may learn from future information that was not available when the decision would have been made.

Serving speed
Some models need features within milliseconds. A checkout fraud model cannot wait for a warehouse query that takes thirty seconds. An online store serves the latest feature values quickly by key.

Offline versus online store

Most feature-store architectures separate two needs.

Offline store
The offline store holds historical feature values for training, batch scoring, backtesting, and analysis. It usually sits on a warehouse, lakehouse, object store, or Delta/Parquet tables. Latency is less important than scale, lineage, and point-in-time correctness.

Online store
The online store serves current feature values for live predictions. It is usually a low-latency key-value system or managed online-serving layer. The model asks for features for customer 123 and gets the latest approved values quickly.

The hard part is keeping both stores aligned. The same feature definition should produce the historical training set and the live value used by the model in production.

Common tools

Feast
Feast is an open-source feature store. It focuses on defining features, creating point-in-time correct training datasets, materialising values to online stores, and serving features for inference.

Databricks Feature Store and Feature Engineering
Databricks has moved feature work towards Unity Catalog. In current Unity Catalog-enabled workspaces, Delta tables with primary keys can serve as feature tables, and online feature stores provide low-latency serving while staying consistent with offline feature tables.

Vertex AI Feature Store
Google's Vertex AI Feature Store uses BigQuery for offline feature data and provides low-latency online serving, feature registry, metadata, and reuse features in the Google Cloud ecosystem.

Tecton
Tecton is a managed feature platform focused on production feature pipelines, batch and real-time features, online serving, monitoring, and governance.

The names matter less than the pattern. You need shared definitions, historical correctness, low-latency serving where required, ownership, and monitoring.

When do you need a feature store?

A feature store is worth considering when:

• multiple production models reuse overlapping features;

• online prediction needs fresh feature values in milliseconds;

• training-serving skew has become a real failure mode;

• you must reconstruct which feature values a model saw at a specific time;

• feature ownership, discovery, and lifecycle management are getting messy.

For one monthly batch model, a feature store may be overkill. A well-tested dbt model, warehouse table, or notebook pipeline with clear definitions can be enough. Do not add a platform layer before the modelling problem needs it.

A simple example

A fraud model needs three features at checkout: number of orders by this customer in the last 24 hours, failed payment attempts in the last seven days, and average basket value in the last 30 days.

For training, the feature store builds historical values as of each old checkout moment. It does not use events from the future. For live inference, the online store serves the latest values for the customer in milliseconds. The model sees the same definitions in both places.

If those features are later useful for a churn model or risk dashboard, the team can reuse them instead of rebuilding the formulas.

What to watch out for

Premature platform work
A feature store without production models becomes an empty catalogue. Start with a real model and a real reuse or serving problem.

Feature sprawl
A feature store can fill with thousands of abandoned features. Give each feature or feature family an owner, documentation, freshness expectation, and retirement rule.

Point-in-time bugs
Future leakage can make offline evaluation look excellent and production performance disappointing. Test time joins carefully.

Online freshness
If a feature is served online, define how often it updates and what happens when the update fails. Stale features can be worse than missing features because they look valid.

Governance and privacy
Features can encode sensitive information even when raw columns are removed. Apply access control, lineage, retention, and privacy review to features, as well as to source tables.

Ignoring monitoring
Track feature freshness, null rate, distribution drift, serving latency, and model impact. A feature store is not just storage; it is part of the production ML system.