LTAP and Lakehouse//RT, One Copy of Data for Everything

Pull-quote: “Every CDC pipeline is a standing apology: we could not serve transactions and analytics from the same data, so we copy it, continuously, and hope.”

Why this matters

The oldest tax in enterprise data is the copy between the operational database and the analytical platform, paid through CDC pipelines that break on schema changes, lag at the worst moments, and quietly corrupt what they carry. Databricks co-founder Reynold Xin put it sharply at DAIS 2026 — CDC, he said, really stands for “continuous data corruption” — and announced two things aimed at the tax itself: LTAP, an architecture unifying transactional and analytical processing on a single copy of lake storage, and Lakehouse//RT, a new SQL warehouse type for millisecond analytics, powered by a new engine called Reyden.

What was announced, with the fine print

The architectural idea is worth stating precisely, because it differs from the last attempt. HTAP tried to run both workload types through one query engine and consistently sacrificed one side or ended up proprietary. LTAP unifies at the storage layer instead: Lakebase keeps serving transactions from row format, the write path produces columnar Delta and Iceberg alongside, and analytical engines read that same governed copy directly. One copy, two access patterns, open formats — Xin called it “HTAP done right.”

What dies when the CDC pipeline dies

   Today                                The LTAP claim
   ─────                                ──────────────
   OLTP ──► CDC ──► staging ──►         OLTP writes ──► row + columnar
        ETL ──► warehouse ──►                 │        (same lake copy)
        serving stack ──► app                 ▼
                                        Analytics / RT queries read
   Each arrow: lag, cost,               the same governed copy.
   schema drift, 2 a.m. pages           No arrows to break.

If the claim holds, the casualty list is long: the CDC tooling line item, the reconciliation jobs that check whether the warehouse matches the source, the freshness SLAs measured in hours, and the separate serving stack — the one that only handles simple queries — kept alive purely because the warehouse could not answer in milliseconds. Lakehouse//RT targets that last one directly, and against existing Delta and Iceberg tables through Unity Catalog, with no data movement.

The honest caveats

LTAP is announced, not shippable; “coming soon” means you cannot architect around it yet, only toward it. Lakehouse//RT is in beta, starts with read-only analytical workloads, and its headline numbers — including the up-to-16x comparison — are Databricks’ own, from preview customer testing. Reyden’s ML-trained algorithm selection is a genuinely interesting engineering bet, and an unproven one outside Databricks’ walls. None of this makes the announcements less significant. It makes the adoption sequence matter.

What we would do with a client estate

Inventory the copy tax now: every CDC pipeline, its failure history, its reconciliation cost, and every serving stack that exists only for latency. That inventory is the business case waiting for LTAP to ship, and it costs nothing to build. Benchmark one real serving workload on the Lakehouse//RT beta — read-only analytics against existing Delta tables is a low-risk trial with a concrete before-and-after. Freeze net-new investment in CDC tooling and dedicated serving infrastructure where a case is pending; renew short. And do not decommission anything on a keynote’s schedule — the pipeline you delete the week before “coming soon” slips is the outage you explain to the board.

Closing

DAIS 2026 attacked the oldest divide in data architecture at the storage layer rather than the query engine, which is why this attempt deserves more attention than HTAP ever earned. The claims are large and the status flags are real: LTAP is coming soon, Lakehouse//RT is beta. Build the inventory, run the benchmark, stop feeding the copy tax — and let the decommissioning wait for GA.