Databricks Feature Views unify training and serving with 200ms latency

Databricks has released Feature Views in public preview, providing a managed abstraction that consolidates historical feature computation and real-time serving under a single Unity Catalog definition, achieving a 200ms end-to-end p99 latency from Kafka event to online availability.

The stack is anchored by the Feature Engineering Client SDK, which operates within Databricks Runtime 14.2 ML. A practitioner can define a feature in a notebook, such as a ten-minute rolling sum of transaction values, and this definition automatically generates both a point-in-time-correct training set and a production pipeline. This approach addresses training-serving skew, a common issue in production ML systems, by storing feature computation logic with the data and enforcing temporal correctness, thus preventing divergence between batch training code and real-time serving code.

Feature Views, when registered in Unity Catalog, become governed objects with lineage and access controls. A single `materialize_features` call provisions the necessary backend infrastructure without additional orchestration. Databricks utilizes Spark Realtime Mode for continuous per-event aggregate updates and Lakebase as the streaming-optimized online store, designed to minimize write amplification during high-frequency small upserts. Spark Realtime Mode calculates rolling windows backward from each event timestamp at millisecond resolution, while Model Serving retrieves features at inference time through autoscaling endpoints within the customer's network boundary.

The 200ms end-to-end p99 latency covers the entire process from Kafka ingestion to online store availability, which is crucial for latency-sensitive applications like fraud detection or travel pricing. Early customer Skyscanner reports that the abstraction reduced feature code volume, allowing data scientists to focus on traveler-value modeling. The platform also supports structured-data retrieval for RAG applications, indicating Databricks' intention to position the feature store as infrastructure for agentic stacks, beyond traditional tabular ML.

However, the preview status implies potential deployment risks, as SLAs, per-feature pricing, and cold-start behavior for autoscaling endpoints are not yet finalized. The 200ms p99 latency is a platform-reported benchmark under Databricks-managed conditions and may vary with Kafka partitioning, event cardinality, and the complexity of rolling aggregations. The managed-service model reduces infrastructure management but limits observability and tuning capabilities compared to a self-managed Flink-to-Redis stack. Migration is non-trivial, requiring existing feature logic to be rewritten into the Databricks SDK, and teams are locked into Databricks' release cycle for critical inference infrastructure.

Architects should consider adopting the API contract, which involves defining features declaratively, automatically enforcing point-in-time correctness, and routing the same logic to both batch training and stream inference with a single materialization call.