TL;DR. LTAP (Lake Transactional/Analytical Processing) is the term Databricks coined on June 16, 2026 for running Postgres transactions directly on lakehouse storage: writes land once, get transcoded to Parquet in Delta and Iceberg format below the engine, and analytics reads that columnar copy plus a merge of very recent changes, without touching the transactional compute. HTAP put the row and column representations inside one engine; LTAP pushes the column representation down into shared object storage and keeps a separate engine per workload. The physics does not change: somewhere, rows still become columns, and critics from CMU's Andy Pavlo to SingleStore's CTO were quick to say so. What genuinely changed is who owns that copy, how isolated the workloads are, and the fact that the analytical format is open. Whether that is a new category or well-engineered HTAP is a naming fight; the trade-offs underneath are measurable, and we measured them.
On June 16, 2026, at its Data + AI Summit, Databricks announced LTAP, Lake Transactional/Analytical Processing, and opened by declaring the previous category dead: HTAP, in their telling, promised to unify transactions and analytics in a single engine but collapsed workload isolation and compromised performance for both. The replacement claim is bold: one copy of operational data, in open formats, in the lake (the S3-style object storage where analytical data already lives), serving both workloads with full isolation and no ETL. Three weeks later The Register was asking what counts as a copy, and TiDB's makers were arguing that LTAP validates HTAP rather than replacing it. Both reactions are partly right, which makes the term worth taking apart carefully rather than cheering or dismissing.
What Databricks shipped underneath the LTAP acronym
The architecture, described in Databricks' engineering post, decomposes Postgres into stateless compute over two storage services. A quorum-replicated write-ahead-log service (SafeKeeper) makes commits durable across nodes instead of on a single disk. A page service (PageServer) consumes that WAL and materializes it into object storage, acting as a row-format cache for the Postgres side, and, this is the load-bearing novelty, transcoding the same changes into Parquet, the lakehouse world's standard columnar file format, wrapped in Delta and Iceberg table metadata as they land in the lake. The transcode runs on spare cycles in the page-serving layer, off the transactional path.
The analytical read path is the other half of the trick. A lakehouse query asks Postgres for exactly one thing: the current log sequence number, a metadata lookup. It then reads the already-materialized columnar data from object storage and merges the small set of changes newer than what has been materialized. Postgres compute serves none of the scan traffic. Freshness is bounded by the WAL-to-lake materialization lag plus that merge, not by a nightly pipeline, and cloning a database becomes a metadata operation because the state already lives in versioned shared storage.
Databricks attaches numbers to some of this: a claim of 5x higher write throughput and 2x lower read latency than comparable synchronous-replication deployments, read latency "indistinguishable from a monolith" on warm caches, and a Lakebase fleet already handling 12 million database launches per day. Those are vendor numbers, unverified here; the architecture description is the part that stands on its own.
The real LTAP vs HTAP difference: where the columnar copy lives
Strip the branding and every system in this family answers one question: given that row layout wins transactions and column layout wins scans by 1.7x to 46x depending on the query, where do you put the second representation and who keeps it fresh? Three answers exist in production.
The family tree in one picture. HTAP unifies the engine and synchronizes inside it; LTAP unifies the storage and lets separate engines read the layer they prefer.
| Engine-level HTAP | Replica-level HTAP | LTAP | |
|---|---|---|---|
| In one sentence | One system keeps both formats and serves both workloads | The cluster ships every write to dedicated columnar nodes | Separate engines share one storage layer that holds the columnar copy |
| Example | Oracle In-Memory, SingleStore | TiDB with TiFlash | Databricks Lakebase |
| Where the columnar copy lives | Inside the engine, in memory | On dedicated replica nodes | In object storage, as Parquet |
| How it stays fresh | Every write maintains both formats | Changes stream to the columnar nodes (Raft learners) | The write-ahead log is converted below the engine |
| Analytical format | Proprietary | Proprietary | Open (Delta, Iceberg) |
| Workload isolation | One box: contention is managed, not removed | Separate nodes inside one cluster | Separate engines; only storage is shared |
| Who runs the row-to-column copy | The database engine | The database cluster | The storage layer |
Read that way, LTAP takes the third seat in the same row rather than repudiating HTAP, and the SingleStore CTO's objection writes itself: you cannot call HTAP a failure while shipping, in his words, "exactly what HTAP promised." But the seat matters. Moving the transcode below the engine buys two things the engine-level designs structurally cannot offer: the analytical copy is in an open format that any Iceberg-speaking engine can read without the operational database's permission, and the two workloads stop sharing a failure domain, which is precisely the property whose absence we measured as a 38 ms worst case becoming 332 ms when a single analytical scan shared a Postgres box with an update stream.
"Zero copies" is marketing; "zero pipelines you operate" is the real claim
The Register's reporting pinned down the semantic sleight. Physically, the data exists as row pages in the page-serving cache and as Parquet in the lake: two representations. A financial-services engineer they quoted called it "Two copies of data, not one," and a Databricks engineer conceded the pageservers amount to a materialization layer. CMU's Andy Pavlo, praising the engineering, still landed the point in six words: "They are copying data out eventually."
The defensible version of the claim is narrower and still valuable: one durable source of truth, in an open format, with the row-to-column conversion owned by the storage layer instead of by a change-data-capture (CDC) pipeline you build, monitor, and apologize for. Databricks' own materials are more careful than the keynote framing; they position zero-ETL competitors as merely hiding the pipeline.
Their engineering post openly documents the caveats. Very small tables are not converted to columnar at all. The intermediate row versions Postgres keeps around for concurrent transactions (MVCC) are invisible to Delta and Iceberg readers and garbage-collected later. Values with no lossless columnar equivalent (NaN, infinities, some numerics, extension types) ride in a structured overflow field. Anyone building on the lake-facing side of LTAP should read that list before assuming Parquet equals Postgres.
The unresolved engineering question is the freshness merge under pressure. The "small set of very recent changes" an analytical query must merge is small precisely when write throughput is modest relative to materialization speed. Our own tail-latency measurements suggest the interesting benchmark nobody has published yet: sustained five-figure write rates with continuous analytical reads, reporting the p99.9 of both sides and the actual staleness distribution. Until someone runs that in public, "full performance isolation" remains a design goal with strong architectural backing rather than a measured fact.
The one thing Databricks and its critics agree on: AI agents broke the OLTP/OLAP boundary
Databricks CEO Ali Ghodsi framed the launch around AI agents: "The infrastructure that powered the last era of computing is now the bottleneck." TiDB's counter-post, arguing every AI agent workload is HTAP, makes the same observation from the other side: a single agent loop reads operational state, retrieves history, searches embeddings, analyzes patterns, and writes back, mixing both workload classes in seconds. The vendors disagree about the fix and agree completely about the cause.
That agreement is worth more than the branding fight. When the caller is an agent, the OLTP/OLAP boundary stops being an infrastructure fact and becomes a per-query fact: the same connection can emit a point lookup and a 50-million-row aggregate one second apart, and read-only access does not make the second one safe on a transactional primary. Storage-layer unification lowers the cost of the analytical half, but the agent still has to understand what it is querying: what the tables mean, how they connect, and where a question of that shape belongs. No storage layout supplies that understanding.
What to take from LTAP if you run Postgres and are not on Databricks
The pattern travels even where the product does not. The direction of the industry, visible in LTAP from above and in extensions like pg_duckdb from below, is: keep the transactional engine row-shaped, land the analytical representation in open columnar formats, and make the synchronization infrastructure someone's product instead of your cron job. If you are choosing today, the decision inputs have not changed, and they are measurable on your own workload in an afternoon: your tail-latency budget on the write path, your freshness budget on the read path, and who you trust to operate the copy. LTAP's contribution is that "the storage layer" is now a credible answer to that last question; its price is that, today, the only full implementation lives inside one vendor's platform, however open the file formats underneath it are.
Frequently asked questions
What does LTAP stand for?
Lake Transactional/Analytical Processing. Databricks coined the term on June 16, 2026 for the architecture combining Lakebase, its Postgres-compatible transactional engine running on object storage, with lakehouse analytics over the same storage layer in Delta and Iceberg formats.
What is Databricks Lakebase?
Lakebase is Databricks' Postgres-compatible transactional database service and the operational half of LTAP. It runs Postgres as stateless compute over two storage services: a quorum-replicated write-ahead-log service for durable commits, and a page service that materializes the log into object storage and transcodes changes into Parquet under Delta and Iceberg metadata. Databricks reports 12 million database launches per day on the fleet, a vendor number we have not verified.
Is LTAP just HTAP rebranded?
Functionally LTAP belongs to the HTAP family: both serve transactions and analytics on shared data with bounded freshness. The genuine difference is placement. HTAP systems keep the columnar copy inside the engine or on cluster replicas in proprietary formats; LTAP materializes it below the engine, in open formats in object storage, with fully separate compute per workload. Critics like SingleStore's CTO argue that delivers what HTAP promised rather than refuting it.
Is LTAP really zero-copy?
Not physically. Data exists as row pages in the page-serving cache and as Parquet in the lake, and Databricks engineers acknowledge the materialization layer when pressed. The accurate claim is one durable source of truth with no user-operated CDC pipeline: the row-to-column conversion happens inside the storage layer, off the transactional path.
Do you need Databricks to get LTAP?
Today, yes, for the full pattern: Lakebase plus lakehouse engines over Unity Catalog, its catalog and governance layer, is the only shipping implementation. The ingredients are appearing elsewhere: pg_duckdb embeds columnar execution in Postgres, and most managed Postgres vendors offer some replica-plus-columnar arrangement, but the WAL-to-open-format materialization below a transactional engine is currently a Databricks product, not a standard.
Why does LTAP matter for AI agents?
Agent workloads mix transactional and analytical statements in a single loop, which both Databricks and its HTAP critics cite as the motivation. Cheap, fresh analytics next to operational data removes the pressure to point agents at a warehouse. It does not remove the agent's need to understand the data it is querying, which is a context problem, not a storage problem.
Where Datapace fits
Datapace comes at the same agent problem from the documentation side. Whichever architecture wins the storage argument, HTAP, LTAP, or a plain replica, the agent still has to understand the base it queries: what is there, what it means, how it connects, and where a question of a given shape belongs. We are building that context layer for production databases, exposed to humans and AI agents over an API and MCP interface, starting with Postgres: fix the base once, and people and models stop re-deriving it badly on every query. It is under construction rather than shipped; if your agents are guessing at your schema today, see what we are building or book a call.
Sources
- Databricks launches LTAP, press release, June 16, 2026
- From monolith to Lakebase to LTAP: rethinking the database from storage up, Databricks engineering blog
- Databricks unifies OLTP and OLAP, depending on what counts as a copy, The Register
- HTAP Database vs LTAP: Why Every AI Agent is HTAP, PingCAP
- Hybrid transactional/analytical processing, Wikipedia
- pg_duckdb: DuckDB-powered analytics in Postgres