What Is a Feature Store and Why Does Production ML Need One?

A feature store is a central system for storing, serving, and reusing feature data across both model training and real-time inference. You need one when the same features must be computed consistently in batch training and low-latency online serving, and when multiple models or teams reuse overlapping features. If you train and serve a single model with a small, stable feature set, a plain database plus some pipeline code may be enough.

The problem a feature store solves

In production ML, features are consumed twice: once in training (batch, historical) and once in inference (online, real-time). If those two paths are built separately, they drift apart.

Three failure modes recur:

• Training-serving skew — the offline feature logic differs from the online logic, so the model sees different inputs in production than it learned on.
• Duplicate computation — each team recomputes the same features, wasting engineering time and compute.
• Online/offline inconsistency — the online store returns stale or differently-scaled values than the training set.

A feature store addresses these by making one definition of a feature serve both paths, with a low-latency online layer and a historical offline layer kept consistent.

What a feature store actually does

Hopsworks describes its Feature Store as "the backbone of production ML," with sub-millisecond retrieval powered by RonDB, and cites Meta's observation that their top 100 features are used in over 100 models — a concrete illustration of reuse. Hopsworks also reports an 80% cost reduction from reusing features and streamlining development, and cites SIGMOD 2024 benchmarks showing 10x lower latency than SageMaker and Vertex for its online store.

Feature store vs. data warehouse vs. model registry

These are often confused because they all "store things" for ML, but their jobs differ:

• Data warehouse — stores raw and modeled analytical data for BI and batch analytics. Optimized for large scans, not millisecond point lookups.
• Operational database — stores application state. Fast key lookups, but no feature-versioning or training/serving consistency concept.
• Model registry — stores trained model artifacts and metadata. It tracks models, not the features they consume.
• Feature store — sits between data sources and models, serving features to both training and inference with one definition.

A feature store typically reads from your existing lakehouse tables (Delta, Iceberg, Hudi) rather than replacing them. Hopsworks, for example, works directly with those open table formats without migrations.

When you actually need one

Introduce a feature store when at least one of these is true:

• You serve models in real time and need low-latency feature lookups.
• Multiple models or teams reuse overlapping features.
• You have been bitten by training-serving skew or inconsistent online/offline values.
• Feature pipelines are duplicated across projects and hard to maintain.

You can likely skip it when:

• You run a single model with a small, stable feature set.
• Inference is batch-only, so there is no online/offline split to reconcile.
• Your team is small enough that a shared library plus a database covers reuse.

The decision is less about scale in the abstract and more about whether you have a real-time serving path and feature reuse across models. Those two conditions are what make the consistency and latency guarantees worth the added infrastructure.