Data Systems

Online vs Offline Feature Stores

A feature store splits into two backends with opposite priorities: an offline store optimized for throughput and an online store optimized for latency.

Two stores, one definition

A feature is defined once but stored twice. The offline store holds the full history of feature values and is read in large scans to build training sets. The online store holds only the latest value per entity and is read one key at a time to serve a live prediction. Keeping a single definition while maintaining two physical stores is the core engineering problem of a feature store.

Offline store

Kronos motion — latency

The offline store is typically a columnar warehouse or a lake table format. It favors throughput: a training job may scan billions of rows to assemble labeled examples. Because it retains history, it supports the point-in-time joins that prevent label leakage. Reads are batch, latency is measured in seconds to minutes, and the access pattern is analytical.

Online store

The online store is a low-latency key-value system. At inference time the service has an entity key, say a sensor identifier, and must fetch the current feature vector in single-digit milliseconds. It stores only the freshest value, so its footprint is small compared to the offline history. Reads are point lookups; the access pattern is operational.

Keeping them consistent

Materialization jobs push computed features into both stores. Two designs dominate. In batch materialization, a scheduled job recomputes features and writes the latest slice to the online store. In streaming materialization, an event pipeline updates the online store continuously so features reflect recent activity within seconds. Freshness requirements decide which you use; fraud detection needs streaming, a weekly churn model does not.

Read paths compared

store	access	priority
offline	batch scan	throughput
online	point lookup	latency

A subtle correctness rule: the value the model sees online must equal the value the same feature logic would have produced offline. Teams verify this with periodic reconciliation jobs that sample entities and compare online reads against a fresh offline computation. Divergence signals a bug in one materialization path.