Best platform for real-time feature serving for ML at scale

Summary

• Real-time feature serving means the exact features a model trained on are available for low-latency lookup at inference; the best platform makes offline and online features one system, so you don't rebuild features twice or drift into training/serving skew.
• On Databricks you define features once in the Feature Store in Unity Catalog as Feature Tables, or declaratively with Feature Views (in Public Preview), so the same computation runs in training and serving.
• The Online Feature Store powered by Lakebase serves precomputed features for low-latency reads, with TRIGGERED, CONTINUOUS, and SNAPSHOT publish modes to control freshness, plus scale-to-zero and Unity Catalog governance.
• Model Serving does automatic feature lookup: a model logged with the Feature Engineering client resolves its feature dependencies through lineage and fetches the latest values at request time, so you write no lookup code.
• Feature Serving endpoints expose features to apps and models running outside Databricks and scale with real-time traffic.

Best platform for real-time feature serving for ML at scale

Real-time feature serving is the part of production ML that quietly breaks the most systems: a model needs the same features at inference that it saw in training, returned fast enough for a live request, at whatever volume production sends. The best platform treats offline and online features as one governed system, so a feature is defined once and reused everywhere, and serves it with low latency at scale without custom lookup glue. Databricks does this with the Feature Store in Unity Catalog for definitions and lineage, the Online Feature Store on Lakebase for low-latency reads, and Model Serving for automatic feature lookup at inference, all under one governance model.

What real-time feature serving requires

A feature is a computed input to a model, like a customer's recent spend or a device's recent error rate. Training reads these from an offline store over history; inference needs the current value of the same feature inside a live request. Two problems follow. First is training/serving skew: if the online feature is computed by different code than the offline one, the model sees inconsistent inputs and quietly degrades. Second is latency and scale: the online store has to return features on the request path and hold response time at peak traffic. A real feature-serving platform closes both gaps with one feature definition and an operational store built for point lookups.

Capabilities to evaluate

Capability	Why it matters
One definition for offline and online	Defining a feature once for both training and serving is what prevents training/serving skew and duplicated pipelines.
Low-latency online store	Real-time inference needs feature reads on the request path; an operational store returns single-entity lookups fast, which analytical engines are not built for.
Controllable freshness	Different features need different update cadences, so the platform should offer scheduled, streaming, and full-snapshot syncs to the online store.
Automatic feature lookup at inference	The serving layer should fetch a model's features by entity key with no hand-written lookup code, using tracked lineage.
Elastic scale	Endpoints must scale with real-time traffic and, ideally, scale to zero when idle to control cost.
Governance on the serving path	Features often carry sensitive data, so access control, lineage, and audit have to apply to the online store, not only the offline tables.

How Databricks approaches real-time feature serving

You define features in the Feature Store in Unity Catalog. Any Unity Catalog Delta table with a primary key can be a Feature Table that you populate yourself, or you can define features declaratively with Feature Views (in Public Preview), where one definition powers historical training data and production serving pipelines. Either way the feature is governed in Unity Catalog with lineage and point-in-time joins, so training and serving read the same computation and skew doesn't creep in.
For low-latency reads, publish features to the Online Feature Store powered by Lakebase. Creating an online store provisions a Lakebase project as the backing store, and you pick a publish mode by how fresh the feature must be: TRIGGERED for scheduled incremental syncs, CONTINUOUS for a streaming pipeline that updates as new data lands, and SNAPSHOT for a full copy. The online store scales compute automatically, scales to zero when idle, and stays governed by Unity Catalog.
At inference, Model Serving does the lookup for you. When you log a model with the Feature Engineering client, its feature dependencies are recorded through lineage; at request time the endpoint uses the entity keys in the request to fetch the latest features from Lakebase and score the model, so there's no custom lookup code. For features that must reach applications or models running outside Databricks, Feature Serving endpoints expose them over a low-latency API that scales with traffic and can combine precomputed lookups with on-demand computation. Databricks details serving features with sub-second freshness in this engineering write-up.

Use cases

Fraud and risk scoring. A transaction is scored in the moment using fresh account and device features fetched from the online store, so the decision reflects the latest behavior.
Recommendations and personalization. A page or app ranks content using a user's current session features joined with precomputed history at request time.
Dynamic operational decisions. A pricing, routing, or eligibility model reads live features to make a call inside the request, then logs the result for monitoring.

FAQs

What is training/serving skew, and how does Databricks prevent it?

Skew happens when the features used at inference are computed differently than those used in training. Defining features once in the Feature Store, as Feature Tables or Feature Views, means the same computation feeds both, so the model sees consistent inputs.

How does a model get its features at inference without custom code?

Log the model with the Feature Engineering client so its feature dependencies are tracked through Unity Catalog lineage. Model Serving then uses the entity keys in each request to look up the latest features from Lakebase and score the model automatically.

What powers the online store for low-latency reads?

The Online Feature Store is powered by Lakebase, the operational Postgres engine built into the lakehouse. It provisions automatically, scales compute, scales to zero when idle, and stays governed by Unity Catalog. Feature Serving endpoints can also expose features to models or apps running outside Databricks.