Feature Store

A feature store is a data system that defines, computes, stores, and serves the input features of machine learning models, so that a model sees the same feature values in training as it does when it makes live predictions. A feature is one model input, such as a card's number of transactions in the past hour, a product's average rating, or an embedding of an image. The store keeps each feature's definition together with its full history in an offline store for building training sets, and its latest value in an online store for fast lookups at prediction time. Uber described a shared feature store in its 2017 post on the Michelangelo machine learning platform. Feast, an open-source feature store started by Gojek with Google Cloud, followed, as did managed feature stores in Amazon SageMaker, Google Vertex AI, Azure Machine Learning, and Databricks.

How a Feature Store Works#

Features start as raw events and tables, and pipelines turn them into model inputs through feature engineering, such as counting a card's transactions over a sliding one-hour window, or through feature extraction with a neural network. A feature store organizes that work into a few components:

• Feature registry: Each feature's name, entity key (the customer, card, product, or camera it describes), data type, transformation code, owner, and version, searchable so that teams reuse features instead of rebuilding them.
• Offline store: Every historical value with its event timestamp, kept in a warehouse or a data lake, used to build training sets and run batch scoring.
• Online store: The latest value for each entity in a key-value database such as Redis or DynamoDB, read in a few milliseconds during inference.
• Materialization: Batch or streaming jobs that compute new values and copy the freshest ones from the offline store into the online store.

At prediction time, a service such as a fraud check sends the card ID, receives the card's current features from the online store, and passes them to the model, keeping inference latency low enough for real-time inference during checkout.

Point-in-Time Correctness#

Each training row must use feature values as they stood when its labeled event happened. A value computed later carries information from the future, a form of data leakage that makes a model look accurate offline and fail in production. Feature stores prevent it with point-in-time joins, which match each label to the latest feature value at or before the label's timestamp for the same entity. The pandas function merge_asof performs the same join:

import pandas as pd

# Offline store: each card's transaction count over the past hour, recorded over time
features = pd.DataFrame(
    {
        "card_id": ["A", "B", "A", "A"],
        "time": pd.to_datetime(["2026-10-01 09:00", "2026-10-01 10:00", "2026-10-01 12:00", "2026-10-01 15:00"]),
        "txn_count_1h": [1, 2, 4, 9],
    }
)

# Labeled events to train on: was each transaction fraud?
labels = pd.DataFrame(
    {
        "card_id": ["B", "A"],
        "time": pd.to_datetime(["2026-10-01 11:00", "2026-10-01 13:30"]),
        "is_fraud": [0, 1],
    }
)

# Point-in-time join: each label gets its card's latest feature value at or before the event time
training_rows = pd.merge_asof(labels, features, on="time", by="card_id")
print(training_rows)

Card A's fraud label at 13:30 receives the count of 4 recorded at 12:00, and the count of 9 recorded at 15:00, after the transaction, stays out of the training set. Card B's label at 11:00 receives its own value of 2, because the by argument matches rows by entity key.

Training-Serving Skew#

Training-serving skew is a gap between the features a model was trained on and the features it receives in production. It appears when a batch SQL job computes training features while separately written application code computes serving features, and the two differ in time zones, window boundaries, units, or how they fill missing values. Google's Rules of Machine Learning devote a section to this skew and recommend logging the features used at serving time so that later training runs can use exactly those values. A feature store removes the duplicate code path by computing each feature once from one definition for both uses, and it records freshness, missing values, and data drift for each feature so that model monitoring can trace a drop in accuracy back to a broken input.

Feature Store vs. Related Systems#

• Data lake: Holds raw and processed files in any format. Many offline stores live inside a lake, with the feature store adding entity keys, timestamps, point-in-time retrieval, and online serving on top.
• Vector database: Finds the stored embeddings most similar to a query vector. A feature store looks values up by entity ID and may hold embeddings as one feature next to counts, averages, and categories.
• Model registry: Versions trained models and their metadata, while the feature store versions the inputs those models consume.
• Model serving: Runs the model behind an API and calls the online store to fetch features for each request.

Features from Computer Vision#

Video analytics turns camera feeds into features for forecasting, anomaly detection, and predictive modeling: hourly visitor counts at a store entrance, queue lengths at checkout, or defect rates per production line, each keyed by camera or line ID and timestamp. In retail, people counting feeds staffing and demand models, and in manufacturing, defect counts per shift feed maintenance models. Ultralytics YOLO object counting produces such values directly: it tracks each detected object across frames and returns running in_count and out_count totals and per-class counts as objects cross a line or region, ready to be written to a feature store as time-stamped values per camera.