What is a Feature Store?
Offline + Online ML Data
A feature store is a data system with two layers — an offline store for batch training and an online store for low-latency inference — that ensures models see the same features in production as they saw during training.
Quick Answer
A feature store is a data system with two layers — an offline store (Parquet/S3) for batch training and an online store (Redis) for low-latency inference. It ensures models trained offline see the exact same feature values as models serving predictions in production, eliminating training-serving skew.
What is a Feature Store?
In machine learning, a feature is a numeric input to a model — things like days_since_last_login, transaction_amount_7d_avg, or user_churn_score. Computing these features consistently across training and serving is harder than it sounds. A feature store solves this with a unified platform that manages feature definitions, history, and retrieval.
Offline Store
Parquet / S3 — Batch Training
Stores historical feature values in Parquet files on S3 or a local filesystem. Used to generate training datasets with point-in-time joins — ensuring labels only see features from before the label timestamp. Handles terabytes of data for model training.
Online Store
Redis — Real-Time Inference
Stores the latest feature values in Redis for sub-10ms lookup during inference. When a prediction request arrives, the model fetches pre-computed features from Redis rather than recomputing them on the fly, enabling real-time serving at scale.
The Problem Feature Stores Solve
Before: Training-Serving Skew
- • Features computed in a notebook using pandas
- • Different SQL query used in production API
- • Aggregation windows differ by 1 hour
- • Model sees different values at training vs serving time
- • Production accuracy silently lower than offline metrics
- • No shared registry — every team recomputes the same features
After: Single Source of Truth
- • Feature definitions stored once in Python FeatureViews
- • Same computation used for training and serving
- • Offline store handles batch; online store handles real-time
- • Point-in-time joins prevent data leakage automatically
- • Features shared across churn, fraud, and personalization models
- • Team ships new model in hours, not weeks
Feature Store Use Cases
Any ML system that needs consistent features at training and serving time benefits from a feature store.
Real-Time Fraud Scoring
Serve transaction features at <10ms to flag fraud before payment clears. Materialize rolling aggregates (7d spend, velocity) to Redis.
Churn Prediction
Generate point-in-time training datasets with engagement features. Serve latest user activity features to the churn scoring API.
Personalization
Share user embedding features across recommendation, ranking, and notification models. Compute once, reuse everywhere.
Credit Risk
Audit feature values at the exact loan application timestamp. Point-in-time correctness is a regulatory requirement.
Recommendation Systems
Serve user and item features at inference time. Offline store generates training pairs; online store powers the live ranker.
Anomaly Detection
Materialize rolling statistical features (mean, std, z-score) to online store. Detect outlier transactions in real time.
How a Feature Store Works
A feature store sits between your raw data and your models. Features flow through four stages:
Defining a FeatureView with Feast:
from feast import FeatureStore, FeatureView, Entity, Field
from feast.types import Float32, Int64
from feast import FileSource
from datetime import timedelta
# Define the data source (Parquet file on S3 or local)
customer_source = FileSource(
path="s3://my-bucket/customer_features.parquet",
event_timestamp_column="event_timestamp",
)
# Define the entity (the join key)
customer = Entity(name="customer_id", value_type=Int64)
# Define the FeatureView
customer_features = FeatureView(
name="customer_features",
entities=[customer],
ttl=timedelta(days=7),
schema=[
Field(name="days_since_last_login", dtype=Float32),
Field(name="transaction_count_7d", dtype=Int64),
Field(name="avg_transaction_amount_7d", dtype=Float32),
],
source=customer_source,
)Point-in-time join for training + online lookup for serving:
import pandas as pd
from feast import FeatureStore
store = FeatureStore(repo_path=".")
# --- TRAINING: Point-in-time correct historical features ---
entity_df = pd.DataFrame({
"customer_id": [1001, 1002, 1003],
"event_timestamp": pd.to_datetime([
"2024-01-15", "2024-01-20", "2024-01-25"
]),
"label": [1, 0, 1], # churned or not
})
training_df = store.get_historical_features(
entity_df=entity_df,
features=[
"customer_features:days_since_last_login",
"customer_features:transaction_count_7d",
"customer_features:avg_transaction_amount_7d",
],
).to_df()
# --- SERVING: Real-time online lookup (<10ms) ---
online_features = store.get_online_features(
features=[
"customer_features:days_since_last_login",
"customer_features:transaction_count_7d",
],
entity_rows=[{"customer_id": 1001}],
).to_dict()Feature Store vs Other Tools
vs Data Warehouse
A data warehouse (BigQuery, Snowflake) stores business metrics — revenue, orders, user counts — optimized for analytics queries by analysts. A feature store stores ML-ready numerical features with time-travel for point-in-time training data and low-latency serving for inference.
Verdict: Use both. Warehouse for business analytics; feature store for ML inputs.
vs MLflow
MLflow tracks experiments and model artifacts — hyperparameters, metrics, and model files. It does not manage the input features. Feature stores manage the input data that goes into MLflow-tracked experiments. They are complementary, not competing.
Verdict: Use both. MLflow for experiment tracking; feature store for feature data.
| Dimension | Feature Store | Data Warehouse | MLflow |
|---|---|---|---|
| Purpose | Manage ML features | Analytics queries | Experiment tracking |
| Storage | Parquet + Redis | Columnar (BigQuery) | Files + metadata DB |
| Latency | <10ms online lookup | Seconds to minutes | N/A (artifact store) |
| Versioning | Point-in-time TTL | Time-partitioned tables | Run/model versions |
| Primary User | ML engineer | Data analyst | Data scientist |
Common Feature Store Mistakes
Computing features differently in training notebooks vs production APIs — the most common cause of model underperformance
Skipping point-in-time correctness in training data joins — leaks future information and inflates offline metrics
Not materializing to the online store before serving — requests fail or fall back to slow recomputation
Treating the feature store like a data warehouse — storing raw business events instead of pre-computed ML-ready features
Who Should Learn Feature Stores?
Junior ML Engineer
Understand why training-serving skew happens and how a feature store prevents it. Learn to define FeatureViews and run feast apply. Immediately applicable to any production ML project.
Senior Data Engineer
Design feature pipelines from raw data to materialized feature stores. Build point-in-time correct training dataset generation. Integrate Feast with Airflow, Spark, and dbt.
Staff / ML Platform
Architect the full ML platform: feature store + model registry + serving infrastructure. Evaluate Feast vs Tecton vs Hopsworks. Define standards for feature naming and TTL policies.
Related Concepts
Frequently Asked Questions
What is a feature store?
A feature store is a data system that manages ML features for both training and serving. It has two layers: an offline store (Parquet/S3) for batch training and an online store (Redis) for low-latency inference. It ensures both layers compute features the same way, eliminating training-serving skew.
What is training-serving skew?
Training-serving skew occurs when features are computed differently during training versus production inference. For example, a days_since_last_login feature computed in a notebook may use a different time window than the same feature computed in your serving API, causing the model to see different distributions and underperform in production.
What is point-in-time correctness?
Point-in-time correctness means joining features to training labels using only data available at the label timestamp. Without it, you leak future information into training data, causing optimistic offline metrics and poor production performance. Feast handles this automatically via get_historical_features().
What is Feast?
Feast is the leading open-source feature store. It defines FeatureViews in Python, supports Parquet for offline storage and Redis for online storage, and provides get_historical_features() for point-in-time training data and get_online_features() for real-time serving.
When do I need a feature store?
When you have more than one ML model in production, when features are reused across models, when you notice drift between notebook-computed and production-computed features, or when real-time inference requires features at sub-10ms latency. Even a single production model benefits from the consistency guarantees.
What You Will Build
Ship a Production Feature Store
- • Feast feature store with offline Parquet + online Redis
- • Point-in-time correct training datasets
- • Real-time feature serving at <50ms
- • Feature reuse across churn, fraud, and personalization models
- • MLflow experiment tracking integrated with your feature pipeline
- • Drift monitoring with Evidently