Mechanism◆Audio · 31:16 — 32:46
Rather than building one unified engine for both transactional and analytical workloads (the historically failed HTAP dream), unifying only the storage layer — writing transactional data in column-oriented format — captures nearly all the benefit without the compromises of a single engine.
Reynold lays out Databricks' LTAP thesis: instead of chasing HTAP's failed goal of one engine for both OLTP and OLAP, unifying just the storage layer so Postgres data lands directly in column format gets 99% of the benefit with no replication lag. ✦ AI generated
Reynold Xin · Latent Space · 2026-06-24 · original ↗
plays this moment only · 31:16 — 32:46
Our whole idea of LTAP, it's obviously a wordplay on the term HTAP, is that we think this is HTAP done right. HTAP wants to build a single engine for both. We think you can get 99% of what you need by unifying the storage, and just have a single storage layer. And once you have the single storage layer, if your Postgres databases are writing data in a column-oriented format, everything analytics can just go read that data directly without any delay.
verbatim transcript · starts at 31:16
- ·HTAP chased one engine for OLTP and OLAP
- ·That unified-engine dream historically failed
- ·LTAP unifies only the storage layer instead
- ·Captures 99% of the benefit, no compromises
- ·Postgres writes data in column-oriented format
- ·Analytics reads that data directly, no delay
- ·No replication lag between transactional and analytical layers
Around this claim