# Databricks real-time mode for Lakeflow pipelines reaches GA

> Real-time mode in Lakeflow pipelines is generally available. Use it for a millisecond decision written to Kafka or a ForEach sink, not a Delta table.

By Sergey Ustimenko, 3 November 2026. Databricks Field Guide, TechFabric. Canonical: https://databricks.techfabric.com/notes/real-time-mode-in-lakeflow-pipelines-is-now/

A scheduled pipeline that writes a Delta table doesn't become a millisecond pipeline because this mode is generally available. We'd leave it on its schedule. [Real-time mode in Lakeflow pipelines](https://docs.databricks.com/aws/en/ldp/real-time) is generally available on classic and serverless compute as of [29 October 2026](https://docs.databricks.com/aws/en/release-notes/product/2026/october#real-time-mode-in-lakeflow-pipelines-is-now-generally-available), and Delta is still not a source or a sink it can use.

We'd turn the mode on only when the output is a decision written to Kafka, Event Hubs or a ForEach writer, and we want the pipeline's recovery around a query that a direct Structured Streaming job has been able to run since [19 March 2026](https://www.databricks.com/blog/announcing-general-availability-real-time-mode-apache-spark-structured-streaming-databricks). The [real-time chapter](15-real-time-and-cdc.md#real-time-mode-the-tier-below-seconds) already draws that line for a direct query. Lakeflow pipelines are the Databricks product this trigger now runs in, built on Apache Spark Declarative Pipelines, which is the name on the [announcement](https://www.databricks.com/blog/announcing-general-availability-real-time-mode-spark-declarative-pipelines-databricks). The [glossary](43-glossary.md#pipelines-and-orchestration) is where those names sit.

We haven't run this mode on a Lakeflow pipeline.

> **Our position**: Turn real-time mode on for a continuous Lakeflow pipeline only when the output is a decision written to Kafka, Event Hubs or a ForEach sink. A flow that lands rows in Delta stays on micro-batch.

## Leave the Delta pipeline on micro-batch

Take a continuous pipeline whose job is to land rows in a Delta table. The [connector table](https://docs.databricks.com/aws/en/ldp/real-time#supported-sources-and-sinks) is what makes the October date a non-event for it. Delta is unsupported on both sides. A stream-to-stream join is unsupported too, so a pipeline that needs one stays on micro-batch even if the sink would otherwise qualify. A ForEach sink can write each row to a store such as Lakebase or Redis, which the [29 October post](https://www.databricks.com/blog/announcing-general-availability-real-time-mode-spark-declarative-pipelines-databricks) states as available now. A native Lakebase sink, with batching, retries and Unity Catalog authentication, is listed there as what comes next. A new design that needs the store now uses ForEach. It doesn't wait on the native sink, and the scheduled table load doesn't need either one.

A second real-time flow in the same pipeline competes for task slots on classic compute and on the current serverless channel, and the latency goes up. Multiple flows without that contention are in Beta, and only on serverless pipelines that use the preview channel. Until that Beta is where we'd run it, the second flow gets its own pipeline.

```mermaid When a Lakeflow pipeline should use real-time mode
flowchart TD
  A["Lakeflow pipeline output"] --> B{"Must a system act in milliseconds"}
  B -->|"No"| C["Keep micro-batch and Delta"]
  B -->|"Yes"| D{"Sink is Kafka, Event Hubs or ForEach"}
  D -->|"No"| C
  D -->|"Yes"| E["Continuous pipeline, RealTime trigger"]
```

## Count the slots before you quote five milliseconds

The five-millisecond line is a floor, and we'd count task slots before quoting it. Classic compute schedules every stage at once. The [sizing table](https://docs.databricks.com/aws/en/ldp/real-time#classic-compute) puts eight source partitions at 8 task slots, and the same source plus a shuffle of 20 at 28. That sum is the estimate. A cluster short of slots doesn't inherit the floor. The checkpoint interval defaults to five minutes, which is how often state and offsets are saved, so a longer interval replays more of a failed batch. The flow has to be an update flow with its trigger set to RealTime, on a pipeline that's already continuous. That configuration is on the [setup page](https://docs.databricks.com/aws/en/ldp/real-time#requirements).

The October post says the Databricks Feature Store reaches a p99 of 200 ms from Kafka to its online feature store on this architecture. That's their query and their store. Read `e2eLatencyMs` on the flow in front of you, and don't quote the floor or the 200 ms as the latency a Delta table load would hit.