Is an online store the same as a model server?

No. It supplies features; a model server performs inference, although an application may connect both.

Does latest mean freshly observed?

Not necessarily. The latest stored record may reflect delayed or stale information.

Can an online store replace all offline storage?

Usually not when historical training data or past-state reconstruction is required.

AI Glossary / MLOps and deployment / Intermediate

Online Store

Definition

An online store is the part of a feature-store architecture designed to retrieve feature values quickly for prediction requests, usually using one or more entity identifiers. It commonly holds precomputed values needed by an online inference application. Its role emphasizes timely keyed access, while an offline store emphasizes historical data access for training and batch work.

What it means

A model may need information beyond what a request directly contains. For example, a request can identify a product while the model also needs that product's recent demand or availability features. The online store supplies those precomputed inputs.
In many designs, it holds the latest stored value for each entity and feature. Feast's documented online store specifically retains latest values rather than historical values. Other implementations should be checked individually rather than assumed to share every detail.
Latest stored does not necessarily mean current in the real world. Freshness depends on collection, feature computation, updates, and propagation. A quick lookup can still return a stale value.

How it works

Feature pipelines compute values and write or materialize them into the online store under suitable entity keys. A prediction application requests the required features, combines them with request-time inputs, and constructs the model's input.
The service must handle missing entities, stale values, errors, and incompatible feature versions. A default value may be appropriate in some cases, but it needs an explicit meaning and suitable model behavior.
Operational requirements include response time under load, availability, throughput, and consistency appropriate to the task. Batch retrieval can reduce the overhead of fetching several candidates or features, but actual performance depends on the store, network, workload, and application design.

Three practical examples

A recommendation ranker can fetch precomputed features for candidate products before calculating their scores.
A support application can retrieve an account's recent interaction features using an account identifier supplied with the request.
An operational monitor can track how old returned feature values are, separately from measuring how quickly the store responds.

Think of it this way

Think of a dispatch desk with a current-status card for each vehicle. Staff can quickly find the relevant card rather than search the full archive. If updates arrive late, however, the card may be outdated despite being easy to retrieve. The analogy highlights lookup and freshness, but real stores also need concurrency, replication, versioning, and failure handling.

Worked example

Consider an invented prediction request at 10:07 for entity E9. The online store returns a feature value of 18 with an event timestamp of 10:00. Assume that timestamp represents the time the underlying observation was valid.
The feature's event age at prediction time is seven minutes. If the application's rule permits at most five minutes of event age, the value is too old under that rule even if the lookup takes only three milliseconds.
Now suppose the same record was written into the store at 10:06. Its storage-write age is one minute, but that does not make the underlying observation one minute old. Measuring only time since the write would hide the six-minute delay between observation and storage.
The application therefore needs to state which age it monitors. A suitable response might be requesting a newer feature, using a documented fallback, or declining the prediction, depending on the task. The store does not choose the business policy merely by returning a value.
For a separate latency illustration, assume sequential processing takes three milliseconds for feature retrieval, eight for model execution, and two for response formatting. Those components total 13 milliseconds before other costs. Real end-to-end latency also includes network and scheduling effects; adding component percentile values is not generally a valid way to derive the overall percentile.

Illustrative case study

In a fictional product-ranking service, newly added products have no precomputed feature records. The application initially substitutes zero for every missing feature and treats the result as a normal product profile.
The team distinguishes missing values from meaningful zeros and develops a tested fallback for new products. It monitors the frequency of fallback use and identifies which upstream pipeline should populate the records.
The case illustrates that an online store's missing-value behavior affects model behavior. Fast lookup infrastructure cannot by itself decide how an unseen entity should be represented.

Common misconceptions and mistakes

Do not equate low latency with fresh data. These are different properties and should be measured separately.
Do not assume an online store retains the history needed for training reconstruction. Some designs deliberately keep only the latest values.
Do not assume the word online means every feature is computed when a request arrives. Many online-store features are precomputed.
Do not silently substitute zeros for missing or expired data. The model and application need a consistent interpretation. Also, avoid copying latency targets from a product example as universal requirements; the appropriate target depends on the complete application.

Business use

An online store supports applications that need feature retrieval within a prediction-time budget. Define the entity keys, required feature set, allowed age, missing-value policy, and expected load before evaluating the implementation.
Monitor both response behavior and data quality. A healthy service dashboard should not conceal stale updates or a rising share of missing entities. Coordinate feature definitions with training data preparation so the online values represent the same intended quantities. This operational agreement matters as much as the physical storage choice.

Check your understanding

A record was written one minute ago, but its observation is seven minutes old. Which age matters for a five-minute observation-freshness requirement?

Answer: The seven-minute observation age. A recent write does not make the underlying observation recent.

Related terms

Offline Store
Feature Freshness
Online inference
Key Value (KV) store
feature store
entity key
materialization
key-value store
and training-serving skew

Learn next

Trace one feature from observation through computation, storage, retrieval, and prediction. Measure or specify each delay, then define the response when the feature is missing or too old for the intended use.

Sources

Sources: Hopsworks dictionary, Online Store: https://www.hopsworks.ai/dictionary/online-store Feast documentation, online-store role and latest-value storage: https://docs.feast.dev/getting-started/components/online-store

Previous: Online search Next: Ontological commitment