Source: Databricks — 2026-08-17

Summary

Databricks Feature Store now serves streaming feature aggregations from Kafka into its online feature store at 200ms p99 latency, down from the minutes-to-hours of staleness typical of batch or microbatch feature pipelines. The gain comes from two changes working together: Spark Real-Time Mode, which processes each event continuously as it arrives instead of collecting events into periodic microbatches, and Lakebase, which separates compute from storage to handle the high-throughput, small, frequent upserts that continuous feature updates require. The result matters most for low-latency inference use cases like fraud detection and real-time recommendations, where a model reading a stale feature value produces a wrong prediction regardless of how good the model itself is.

Key Takeaways

• End-to-end latency from a Kafka event to an updated value in the online feature store is now 200ms at p99 — meaning 99% of updates complete within that window, not just the average case.
• Spark Real-Time Mode replaces microbatching: instead of collecting events for a fixed interval and processing them as a batch, it processes each event as a continuous stream, which is the primary latency win.
• Lakebase contributes the storage-side fix: separating compute from storage lets the system absorb high-throughput, small, frequent upserts — the access pattern continuous feature updates generate — without the write contention a traditional coupled storage layer would hit.
• Traditional batch or microbatch feature pipelines leave features stale by minutes to hours; this architecture collapses that gap to milliseconds.
• The stated use cases are latency-sensitive by nature — fraud detection and real-time recommendations — where a model scores a request using whatever feature value is currently stored, so a stale value (e.g., an account balance or click history from 20 minutes ago) directly produces an incorrect prediction.
• This is a serving-layer change, not a model change: the ML model itself doesn't need to be retrained or modified to benefit — it just reads fresher inputs at inference time.

Reel Script

Hook: A fraud model can be perfectly trained and still make the wrong call — if it's scoring a transaction using an account balance from twenty minutes ago. Databricks just cut that staleness window from minutes down to 200 milliseconds.

Core Concept: A feature store is the system that sits between raw event data and a live model — it computes things like "transactions in the last 5 minutes" or "average order size this week" and stores the current value so a model can look it up instantly at inference time instead of recomputing it from scratch on every request. The problem with most feature stores is how they refresh: traditional pipelines run on a batch or microbatch schedule, collecting events for some interval — a minute, an hour — before computing updated feature values. That means at any given moment, a model reading a feature might be looking at data that's stale by however long that interval is. Databricks fixed this by replacing the batch step with Spark Real-Time Mode, which processes each event individually as it arrives rather than waiting to accumulate a batch — think of it like a cashier scanning each item as a customer hands it over instead of waiting for the whole cart to be unloaded first. But fast computation alone doesn't help if the storage layer can't keep up with writing that many small updates that frequently, which is where Lakebase comes in: by separating compute from storage, it can absorb a high-throughput stream of small upserts without the write bottleneck a traditional coupled database would hit under that same load.

Hands-On: The pipeline worth diagramming has four stages in sequence: an event lands in Kafka (say, a card swipe), Spark Real-Time Mode picks it up and recomputes the relevant feature aggregation immediately rather than batching it, that updated value gets written into Lakebase's online feature store via a small upsert, and a model serving a fraud-check request reads that value at inference time. The number that makes this concrete is the p99 latency across that whole chain: 200 milliseconds, meaning 99 out of 100 updates complete that fast, not just the typical case. Compare that against what it's replacing — the piece worth stating plainly on camera — traditional microbatch pipelines leave a feature stale by minutes to hours depending on the batch interval, so a system built the old way could easily be serving a fraud model data that's 15, 30, 60 minutes old at the exact moment a fraudulent transaction is happening.

Takeaway: For any team running real-time fraud detection or recommendation models, feature freshness is often the actual bottleneck on model accuracy, not the model architecture — and a 200ms p99 pipeline removes staleness as an excuse. If your production ML system still runs on microbatch feature updates, that gap is worth quantifying against this benchmark.

Discussion