What Is a Real-Time Feature Store?
A real-time feature store is a feature store that serves machine learning features reflecting events from the last few seconds, not only the last batch run, fast enough for an online prediction. It adds two paths to a batch feature store: streaming or push ingestion that updates feature values in the online store shortly after events occur, and request-time transformations computed when the prediction is requested. An offline store keeps feature history so that models train on the same feature definitions they are served.
Updated
What is a real-time feature store?
Uber's 2017 post introducing Michelangelo, its in-house ML platform, described a shared Feature Store and two ways to compute features for online serving: bulk precomputation loaded from HDFS into Cassandra on a regular basis, and near-real-time streaming jobs that read metrics from Kafka, computed aggregates with Samza and wrote them to Cassandra.
In current feature stores, "real-time" covers two kinds of features beyond batch. Tecton's feature view docs name all three: Batch Feature Views materialize feature data "on a schedule," Stream Feature Views "transform features in near-real-time against a Stream Source, or Push Data Source," and Realtime Feature Views "run transformations at request time." Feast covers the same ground with push sources, which "allow feature values to be pushed to the online store and offline store in real time," and on-demand feature views, which combine existing features with "request-time data."
For feature store architecture in general, and a comparison of Feast, Tecton and AWS, see What is a feature store?. This entry covers only what makes one real-time.
How a real-time feature store works
Take one feature, card transactions in the last ten minutes, used by a fraud model. There are three ways to produce it:
| Path | How the value is produced | How old the value can be |
|---|---|---|
| Batch | A scheduled job over the warehouse writes it to the online store | Up to the job interval, plus run time |
| Streaming | A stream job consumes the event stream and updates the online store | The pipeline's end-to-end lag, which can grow under load |
| Request time | Computed from raw events when the prediction is requested | As fresh as the raw events the query can see |
The request-time version is a plain query:
SELECT count(*) AS txn_10m,
coalesce(sum(amount), 0) AS amount_10m
FROM card_events
WHERE card_id = $1
AND event_time > now() - interval '10 minutes';Request-time computation gives the freshest value, but it adds work to every prediction and needs the raw events queryable at serving speed. A real-time feature store lets one model mix all three: slow-moving features in batch, recent aggregates on the streaming path, and cheap row-level transforms at request time. In Tecton, a Realtime Feature View can itself take a Batch or Stream Feature View as input.
Training has to see the values the model would have seen. The offline store returns each feature as of each training example's timestamp, which is called point-in-time correctness. When the serving path computes a feature differently from the training path, for example a Spark job for training and a stream job for serving, the model gets different inputs in production than it learned on. That is training-serving skew, and it is a main reason to define each feature once.
Why real-time feature stores matter in real-time systems
Fraud and abuse often arrive as a burst. Suppose, as an illustration, that a stolen card is tested with six small purchases in forty seconds. An hourly batch feature reports zero. A streaming feature reports them once the pipeline catches up, which may be after the seventh purchase is approved. A request-time count over committed events sees all six. What matters is the freshness of each feature, not the pipeline's average: the velocity count must be current, while a customer's 90-day average can lag without harm.
Some problems are beyond any feature store design. Two authorizations on the same card at the same instant each read a count that excludes the other. Fresher features don't fix that. The decisions themselves have to be recorded and checked in one serialized transaction, so the second one sees the first or retries.
In Tacnode, features are defined in SQL over the same store the decision reads from. Expensive aggregates are incremental views, refreshed incrementally on a schedule you set in SQL, typically every few seconds. Features that must reflect the latest write are computed on demand against the latest committed data. Feature freshness explained covers how to measure the lag in an existing stack.
FAQ
Related terms
Derived context is state computed from events rather than stored directly — aggregates, velocity counts, features, embeddings — that decisions consume.
Change data capture (CDC) identifies row-level database changes and delivers them to downstream systems as ordered events. Learn how log-based CDC works.
A freshness budget is the maximum staleness a decision can tolerate in its inputs — and it equals the worst input, since one slow signal spends it all.
A validity window is the interval within which a decision's context remains an accurate basis for action — typically 10ms to 1s for automated decisions.
Decision-time analytics is the pattern where analytical query results directly drive automated decisions — not dashboards reviewed by humans later.
Live context is decision context kept close to current: reads hit the latest committed data, and derived state refreshes incrementally, typically every few seconds.
Training-serving skew is a difference between a model's performance in training and in production, often because serving computes its features differently.
Point-in-time correctness means each training example gets feature values as they stood at the label's timestamp, never later ones, so no future data leaks.