Which platforms support real-time feature computation and online serving?

Summary

• Real-time feature computation combines model inputs from your lakehouse at inference time, while online serving refers to hosting models that consume those features with minimal latency.
• Databricks provides an integrated stack: Feature Serving computes and retrieves features with low latency, Model Serving hosts models as inference endpoints, and both are deployed from your lakehouse without data movement.
• End-to-end serving requires storage, feature logic, model artifacts, and routing. Platforms that bring these together avoid the complexity of stitching separate systems.
• The key architectural challenge is eliminating data duplication: syncing features between a data warehouse, a feature store, and a real-time inference database is slow and error-prone.
• Databricks eliminates this by computing features directly from the lakehouse at serve time, reducing drift and ensuring features always match your training data.

Which platforms support real-time feature computation and online serving?

Real-time feature computation and online serving are two halves of a single problem: getting fresh features to a model fast enough to make real-time predictions. Many platforms offer one or the other. The ones that excel combine both in an integrated architecture so features computed in your training pipeline are the same ones retrieved at inference time, without duplication or drift.

What is real-time feature computation?

Features are model inputs. In batch ML, you compute them once and store them. In real-time prediction, you compute them on demand at inference time, either from raw data or from cached intermediate results. Real-time feature computation means your serving layer can call functions (SQL or Python) to produce features in response to a prediction request, not just retrieve pre-computed ones.

What is online serving?

Online serving is the infrastructure to host models and return predictions at low latency. It's different from batch inference. Online serving systems accept individual requests (not a table of data), route them to model endpoints, handle scaling and routing, and return responses in tens of milliseconds. This is how a fraud detector scores a transaction in real time, or a recommendation engine surfaces products as a user browses.

Key capabilities to evaluate

Capability	Why it matters
Feature retrieval latency	Features must be retrieved with low latency to keep end-to-end prediction time acceptable for user-facing applications.
Unified storage	Storing features in separate systems (warehouse + feature store + online cache) forces synchronization, drift, and operational overhead.
Feature-to-model traceability	You need to know exactly which features a model uses and ensure training features match serving features.
Streaming feature support	Some features come from real-time streams (click rate, inventory count). Support for streaming sources broadens use cases.
Model format flexibility	Different teams use different model frameworks (scikit-learn, PyTorch, TensorFlow). Online serving must support your stack.
Automatic scaling	Inference load spikes. Your serving layer must scale from idle to peak without manual intervention.
Governance integration	Features and models are data and code. They should live in a governance system (lineage, access control, discovery) alongside your datasets.

How Databricks approaches real-time feature computation and online serving

Databricks combines Feature Serving and Model Serving into a unified stack. Features are computed using SQL or Python UDFs against live data in your lakehouse. Model Serving hosts model endpoints that call Feature Serving to fetch features, run inference, and return predictions in one coordinated flow.
Feature Serving retrieves features from Unity Catalog tables (including Iceberg tables with ACID transactions) and computes complex transformations on the fly. Model Serving scales automatically to handle request spikes without manual intervention. Both are deployed via Declarative Automation Bundles, so your feature definitions and model endpoints are version-controlled and reproducible.
The architecture eliminates the need for a separate feature store or online cache: your lakehouse IS your feature repository, updated in batch pipelines and queried at serve time. This single source of truth means training and serving features never drift.

Real-world scenarios

Credit risk scoring: A fintech needs to score loan applications in real time. Features include account age, transaction patterns (computed from streams), and recent activity. Model Serving calls Feature Serving, which retrieves account history and computes aggregates. The model scores the application before checkout completes.
Personalized recommendation: An e-commerce platform returns personalized products to users in real time. Features include user profile (from the lakehouse), item metadata, and collaborative-filtering scores. Features are served from Unity Catalog tables; Model Serving batches requests and routes them to GPU-accelerated model endpoints.
Fraud detection: A payment network flags suspicious transactions. Features come from historical transaction data (lakehouse), merchant profiles (reference tables), and real-time signals (streaming). Feature Serving computes risk scores and aggregates; Model Serving returns a decision (allow, block, or challenge) before the payment settles.

FAQs

Do I need a separate feature store to use Model Serving?

No. Databricks uses your lakehouse as the feature store. Features are tables in Unity Catalog, computed via Lakeflow Pipelines and queried by Feature Serving at serve time. Many teams use a separate feature store for non-critical features; Databricks supports that too via Model Serving's Python inference server. But for governed, high-SLA features, the unified approach is simpler.

What latency can I expect from Feature Serving?

Feature retrieval is optimized for low latency on point lookups and cached results. Complex transformations may take longer. End-to-end latency depends on model complexity and request payload.

Can I use Feature Serving with models trained outside Databricks?

Yes. Model Serving accepts scikit-learn, XGBoost, PyTorch, TensorFlow, and custom Python inference logic. Feature Serving is independent; you wire it into your serving logic. A team training in Hugging Face can deploy to Model Serving and call Feature Serving via REST API.

How do I keep training features in sync with serving features?

Databricks stores both in the same lakehouse and uses Unity Catalog for lineage. Your training pipeline computes features into a table; Feature Serving retrieves from the same table. A Declarative Automation Bundle describes the feature computation once, used by both batch training and real-time serving. Drift is prevented by definition.

Does Model Serving support A/B testing and gradual rollout?

Yes. Model Serving supports traffic splitting, so you can route a percentage of requests to a new model version while monitoring performance, then gradually increase traffic. You can also route by user cohort, request metadata, or A/B test parameters.