Is HTAP dead, and what is replacing it?

Summary

• HTAP hit architectural limits. Hybrid Transactional/Analytical Processing tried to serve both transactions and analytics from one engine, which forced trade-offs: noisy-neighbor contention, compute that could not scale independently, and tightly coupled storage and compute.
• LTAP is the modern successor. Databricks introduces LTAP (Lake Transactional/Analytical Processing), which unifies data at the storage layer instead of the engine layer, so purpose-built engines share one logical copy of data.
• Lakebase is the transactional foundation. Lakebase is a fully managed, serverless PostgreSQL database that handles transactions with full ACID semantics while the lakehouse handles analytics.
• One copy, open formats, no CDC plumbing. Data written by Postgres transactions lands in the lake in open columnar formats and is available to analytical engines without replicas or change-data-capture pipelines to keep in sync.
• Adopt without migration. Lakebase stays standard Postgres, so existing drivers, extensions, indexes, and application code keep working; LTAP capabilities can be added incrementally.

Is HTAP dead, and what is replacing it?

HTAP (Hybrid Transactional/Analytical Processing) is an architecture pattern that tried to run transactional and analytical workloads inside a single engine. In practice that design ran into fundamental limits: analytical scans and transactional point reads compete for the same resources (noisy-neighbor effects), compute for the two workload types cannot scale independently, and storage and compute stay tightly coupled. Forcing one engine to excel at both row-oriented OLTP and columnar OLAP compromises performance on both fronts. Databricks addresses this with a different approach called LTAP (Lake Transactional/Analytical Processing), built on Lakebase.

Why Databricks Lakebase and LTAP replace HTAP

LTAP unifies data at the storage layer rather than the engine layer, so each workload runs on an engine built for it while sharing one logical copy of data. See the LTAP overview for the full architecture.

• Purpose-built engines on one copy. Postgres serves transactions with full ACID semantics and low-latency point reads, while lakehouse engines serve analytics. Analytical reads are isolated from the primary Postgres instance, so they do not compete with transactional traffic.
• Single logical copy in open storage. Data lives in the lake as columnar Parquet, readable through open table formats such as Delta and Iceberg. Both engines read one copy with no replicas to keep in sync. Each engine can cache or represent data in the physical format it needs, so Lakebase uses Postgres pages for fast OLTP reads while analytical engines read columnar Parquet.
• Universal governance. Unity Catalog governs access to that one logical copy across both workloads, applying consistent permissions, lineage, and audit.
• Serverless Postgres that separates compute and storage. Lakebase externalizes the write-ahead log and data files into independent cloud services, so stateless Postgres compute scales independently from durable, distributed storage. This unlocks elastic compute, durable writes, simpler high availability, and instant branching.
• Scale-to-zero and fast starts. Compute spins up to process queries and scales down when idle, with fast auto-scaling and sub-second cold starts, so you do not maintain always-on infrastructure.
• Instant branching and point-in-time recovery. Developers can create a full-fidelity, copy-on-write branch of a live production database in seconds to reproduce edge cases safely, and Lakebase provides near-instant point-in-time recovery regardless of data size.
• Synced tables and Change Data Feed. Synced tables serve Unity Catalog table data in Lakebase for low-latency OLTP reads, and Change Data Feed stores row-level changes from Lakebase Postgres tables as Unity Catalog Delta tables for downstream pipelines and audit, with roughly 10-second average freshness and no separate CDC infrastructure to run.

Getting started

• Read Lakebase and the LTAP architecture: rethinking database storage for how storage-layer unification works.
• Review the LTAP overview and architecture documentation.
• See What is a Lakebase? and Lakebase is now generally available to plan adoption.
• Learn why agentic software development is changing databases.

FAQs

Is HTAP dead?

The single-engine HTAP pattern ran into architectural limits at scale, including noisy-neighbor contention and compute that could not scale independently. Databricks addresses those limits with LTAP, which unifies data at the storage layer so purpose-built engines share one copy of data.

What is LTAP?

LTAP stands for Lake Transactional/Analytical Processing. It keeps one logical copy of data in open formats in the lake, lets Postgres handle transactions and lakehouse engines handle analytics, and governs both with Unity Catalog.

Do I need CDC pipelines with LTAP?

No. When data written by Postgres transactions lands in the lake, it is available to analytical engines in open columnar formats without a separate copy or change-data-capture pipeline.

Do I have to migrate my application to adopt LTAP?

No. Lakebase remains standard Postgres, so existing extensions, indexes, queries, and application code continue to work, and you can adopt LTAP capabilities incrementally.