# Feature store

A feature store manages machine learning features so the same definitions feed training and real-time serving, with point-in-time correctness. Learn how it works.

## Overview

A feature store is a system for managing the inputs that machine learning models use, called features. A feature is a measurable property, such as "number of orders a customer placed in the last 30 days" or "average transaction amount this week". A feature store keeps one definition of each feature, computes or ingests its values, and serves them in two ways: as large historical tables for training, and as fresh single values in milliseconds for live predictions.

An everyday picture: a restaurant group with a central prep kitchen. Sauces and stocks are made once to a fixed recipe and stored in labelled containers. Every branch, and every trainee chef practising a new dish, draws from the same containers. Nobody re-invents the sauce, and the dish tastes the same in training as it does for paying guests. A feature store is that central kitchen for model inputs.

The main problem it solves is training-serving skew: the quiet bug where a model is trained on features computed one way in a data warehouse and then served features computed differently by application code. A second problem is data leakage, where training rows accidentally include information from the future. Feature stores address both, and they also make features discoverable and reusable across teams.

## What it is

| Component | Purpose |
|---|---|
| Feature definitions | Named, versioned descriptions of features, their source and their entity |
| Entities | The keys features describe, such as customer, card or product |
| Offline store | Historical feature values, usually in a warehouse or lakehouse, for training and batch scoring |
| Online store | Latest feature values in a low-latency key-value store for real-time inference |
| Materialisation | The process that copies fresh values from offline sources into the online store |
| Point-in-time joins | Joins that attach to each training row only the feature values known at that row's timestamp |
| Transformations | Batch, streaming or on-demand computations that produce features |
| Registry | The catalogue of definitions, owners and metadata, used for discovery and governance |
| Monitoring | Checks of freshness, completeness and distributions of feature values |

Typical offline stores include [BigQuery](/tools/bigquery), [Snowflake](/tools/snowflake), [Amazon Redshift](/tools/amazon-redshift) or files in a lakehouse. Typical online stores include [Redis](/tools/redis), DynamoDB or [Cassandra](/tools/cassandra).

## Where it came from

The term became widely known in 2017, when Uber described Michelangelo, its internal machine learning platform, which included a shared feature store so teams could reuse curated features. Other large technology companies built similar internal systems.

In January 2019 Gojek and Google Cloud announced Feast, an open-source feature store, to make the pattern available to everyone. Feast later joined the Linux Foundation's LF AI and Data umbrella and evolved into a lighter, pluggable framework that works with many offline and online stores. Commercial feature platforms appeared from 2019 onwards, some founded by people who had built Michelangelo, and the major cloud and data platforms added managed feature stores, including those in [SageMaker](/tools/sagemaker), [Vertex AI](/tools/vertex-ai) and [Databricks](/tools/databricks).

## How it works

### Defining features

A team writes definitions in code or configuration: the entity key, the source table or stream, the timestamp column, the feature names and types, and how long a value stays valid. These definitions are registered so that others can find and reuse them.

### Computing values

Features come from three kinds of computation:

- **Batch** features are computed on a schedule in the warehouse, for example daily aggregates.
- **Streaming** features are updated continuously from event streams such as [Apache Kafka](/tools/apache-kafka), for example "transactions in the last five minutes".
- **On-demand** features are computed at request time from request data, for example "distance between this purchase and the customer's home".

### Building training data

To build a training set, a data scientist provides an "entity dataframe": a list of entity keys and event timestamps, often with labels. The feature store performs a point-in-time join, finding for each row the most recent feature value at or before that timestamp. This prevents leakage from future data.

```python
from feast import FeatureStore

store = FeatureStore(repo_path=".")
training_df = store.get_historical_features(
    entity_df=orders_df,  # columns: customer_id, event_timestamp, label
    features=["customer_stats:orders_30d", "customer_stats:avg_amount_7d"],
).to_df()
```

### Serving online

Materialisation jobs copy the latest values into the online store. At prediction time, the application asks for features by entity key and receives them in milliseconds, with the same names and definitions used in training.

### Governance and monitoring

The registry records owners, descriptions and which models use each feature. Monitoring checks that online values are fresh, that batch jobs completed, and that distributions have not shifted unexpectedly, which links feature stores closely to [model monitoring](/tools/model-monitoring).

## Key concepts and terms

| Term | Meaning |
|---|---|
| Feature | A measurable input to a model |
| Entity | The object a feature describes, identified by a key |
| Feature view | A group of related features from one source, in Feast terminology |
| Offline store | Storage of historical feature values for training |
| Online store | Low-latency storage of the latest values for inference |
| Materialisation | Loading fresh values into the online store |
| Point-in-time join | A join that uses only values known as of each row's timestamp |
| Time to live | How long a feature value remains valid for serving |
| Training-serving skew | Mismatch between features in training and in production |
| Data leakage | Training data that contains information unavailable at prediction time |
| On-demand feature | A feature computed at request time |

## A worked example

This scenario is illustrative. A card issuer runs a fraud model that must answer in under 50 milliseconds.

1. The team defines three features on the `card_id` entity: transactions in the last hour (streaming), average amount over 30 days (batch, daily) and distance from the last transaction (on-demand).
2. To train, they take 4 million labelled historical transactions with timestamps and request features through a point-in-time join. A transaction from 14 March at 10:02 receives the 30-day average computed on 13 March, not a value that already includes later spending.
3. Daily materialisation loads 30-day averages for 12 million cards into the online store. A streaming job keeps hourly counts current.
4. At authorisation time the service fetches two features by `card_id` in about 5 milliseconds, computes the distance feature from the request and calls the model.
5. Before the feature store, the online service computed the hourly count with slightly different logic, and the model's precision in production was 6 points lower than in testing. With shared definitions, the gap closes to within normal variation.
6. A credit-limit team later discovers the 30-day average in the registry and reuses it instead of building its own.

## Strengths and limitations

**Strengths:**

- Removes training-serving skew by sharing one definition.
- Prevents leakage with point-in-time correct training data.
- Encourages reuse and discovery across teams and models.
- Separates feature engineering from model code.
- Provides a natural place for feature monitoring and governance.

**Limitations:**

- Another system to build, operate and pay for.
- Online stores and streaming pipelines add operational complexity.
- Overkill for a few batch models with no real-time needs.
- Value depends on discipline: undocumented or duplicated features erode trust.
- Streaming and on-demand features are harder to keep identical across offline and online paths.

## How it compares with alternatives

| Approach | What it offers | When it fits |
|---|---|---|
| Open-source feature store such as Feast | Definitions, point-in-time joins, online serving on your own infrastructure | Teams wanting control and portability |
| Managed cloud feature store | The same ideas, operated by the cloud provider | Teams committed to one cloud platform |
| Plain warehouse tables and [dbt](/tools/dbt) | Batch features as SQL models | Batch-only use cases |
| Caching in [Redis](/tools/redis) by hand | Fast lookups | Few features, one model, small team |
| Computing features in application code | No extra system | Prototypes only; high skew risk |

## Practical guidance and best practices

1. Start with features that several models share, where reuse pays back quickly.
2. Always build training sets with point-in-time joins, never with plain latest-value joins.
3. Give every feature an owner, a description and a freshness expectation.
4. Set time-to-live values so stale online data is not served silently.
5. Monitor materialisation jobs and online freshness, with alerts.
6. Keep transformations in one place used by both offline and online paths.
7. Log the features actually served with each prediction, so you can audit and retrain.
8. Review and retire unused features regularly.

## Common mistakes

- Joining labels to the latest feature values, which leaks future information.
- Writing separate logic for online and offline versions of the same feature.
- Ignoring time zones in timestamps, which shifts point-in-time joins.
- Building a feature store before having any model in production that needs it.
- Letting definitions multiply with near-duplicate names and no owners.
- Not monitoring freshness, so models run on values that stopped updating.

## Frequently asked questions

### Do I need a feature store?

Not always. If you have a few batch models and no real-time predictions, warehouse tables may be enough. A feature store pays off when several models share features, when predictions need fresh data in milliseconds, or when skew and leakage have already caused problems.

### What is a point-in-time join?

It is a join that, for each training example, picks the feature value that was known at that example's timestamp. It reproduces what the model would have seen in production at that moment.

### What is the difference between the offline and online store?

The offline store holds full history, optimised for large scans when building training sets. The online store holds only the latest values, optimised for very fast lookups by key during live predictions.

### Is Feast a database?

No. Feast is a framework that sits on top of existing databases. It uses your warehouse or files as the offline store and a key-value store as the online store, and it manages definitions, joins and materialisation.

### Are feature stores useful for LLM applications?

Sometimes. LLM applications often need fresh structured context, such as a customer's plan or recent orders, inside a prompt. A feature store can serve that context consistently, alongside retrieval from documents.

## Glossary

- Entity key: the identifier used to look up features, such as a customer ID.
- Event timestamp: the moment a training row or feature value applies to.
- Backfill: computing historical values for a new feature.
- Freshness: how recently a feature value was updated.
- Streaming feature: a feature updated continuously from events.
- Key-value store: a database that returns a value quickly for a given key.
- Lineage: the record of which data and jobs produced a feature.

## Summary

A feature store keeps one definition of each model input and serves it both as point-in-time correct history for training and as fresh values for real-time inference, which removes training-serving skew and prevents leakage. The pattern spread after Uber described Michelangelo in 2017, and open-source Feast, launched by Gojek and Google Cloud in 2019, made it widely available, with managed options now on every major platform. It is most valuable when features are shared and predictions are real time, and it works best with clear ownership, freshness monitoring and strict use of point-in-time joins.