What is the difference between an operational data store, HTAP, LTAP, and lakehouse-connected Postgres?

Summary

• Short answer. These describe four ways of handling transactional (operational) and analytical data. An operational data store is an engine-level transactional pattern, HTAP is an engine-level pattern that tries to combine both workloads, LTAP is a storage-level architecture, and lakehouse-connected Postgres is how Databricks Lakebase implements LTAP.
• Operational data store (OLTP). A row-oriented, application-facing database optimized for fast reads and writes on individual records — the transactional system applications and AI agents talk to.
• HTAP. Hybrid transactional/analytical processing serves both transactional and analytical queries from a single engine, which couples storage and compute and lets the two workloads contend for the same resources.
• LTAP. Lake transactional/analytical processing unifies the two workloads at the storage layer, keeping purpose-built engines for each — Postgres for transactions and lakehouse engines for analytics — over one logical copy of data under one governance model.
• Lakehouse-connected Postgres. Databricks Lakebase is standard, serverless Postgres that implements LTAP: its data is governed in Unity Catalog and served through synced tables, so operational data is available for analytics without separate copy pipelines or application changes.

What is the difference between an operational data store, HTAP, LTAP, and lakehouse-connected Postgres?

These terms describe different ways to handle two kinds of database work — transactional (operational) processing and analytical processing — and how much they separate or combine the engines and storage that do each job. Databricks Lakebase, a fully managed, serverless, PostgreSQL-compatible database, uses the LTAP architecture, which is what makes it a lakehouse-connected Postgres. See Lakebase and LTAP.

How each pattern differs

• Operational data store / OLTP. An operational data store is a row-oriented, application-facing database optimized for fast reads and writes on individual records — online transactional processing (OLTP). It is the system applications and AI agents read from and write to in real time. Lakebase is this kind of database.
• OLAP (analytical). Online analytical processing engines are column-oriented and optimized for scanning large volumes of data across many rows, using open formats such as Delta Lake and Apache Iceberg (Parquet). This is what the lakehouse is built for.
• HTAP (hybrid transactional/analytical processing). HTAP aims to serve both transactional and analytical queries from one engine. Because both workloads share the same engine, storage and compute are coupled and analytical scans can contend with transactional operations for the same resources.
• LTAP (lake transactional/analytical processing). LTAP unifies transactional and analytical workloads at the storage layer rather than in a single engine. Purpose-built engines handle each job — Postgres serves transactions with full ACID semantics and the lakehouse serves analytics — while both operate over a single logical copy of data in open storage under one governance model. See The three pillars of LTAP.
• Lakehouse-connected Postgres. This is Databricks' implementation of LTAP: Lakebase stays standard Postgres — with indexing, extensions, branching, and low-latency point reads and writes intact — and its data connects to the lakehouse so it can be governed and analyzed with no data migration and no application changes.

The three pillars of LTAP

• Universal governance. Unity Catalog governs analytical access to one logical copy of the data across both workloads. See Lakebase projects.
• Purpose-built engines. Postgres serves transactional workloads and lakehouse engines serve analytics. Each engine keeps its own physical representation of the data for performance, while you work with a single logical dataset.
• A single logical copy in open storage. Both engines read one copy of data in open formats (Delta Lake / Iceberg as Parquet), so there are no replicas or pipelines to keep in sync. See How this architecture supports LTAP.

Why Databricks Lakebase for lakehouse-connected Postgres

• Standard, serverless Postgres. Lakebase is PostgreSQL-compatible, so existing extensions, indexes, queries, and application code keep working, and adopting LTAP capabilities requires no data migration or application changes. See Lakebase projects.
• Registered in Unity Catalog. Lakebase data can be registered in Unity Catalog to govern analytical access and run cross-source queries from the lakehouse.
• Served with synced tables. Synced tables serve Unity Catalog table data into Lakebase for low-latency operational reads, keeping operational and analytical data in sync without hand-built pipelines.
• One logical copy, purpose-built engines. By unifying at the storage layer, Lakebase avoids the resource contention and coupled storage/compute that come with running one engine for everything, while keeping full transactional (ACID) semantics for Postgres.

Getting started

• Read the Lakebase and LTAP overview to understand how transactional and analytical workloads share one logical copy of data.
• Review Lakebase projects for the managed, serverless Postgres experience.
• See how the storage layer supports LTAP in Lakebase architecture.
• Read the engineering perspective in Lakebase and LTAP: rethinking database storage.

FAQs

Is Lakebase an operational data store?

Yes. Lakebase is a fully managed, serverless, PostgreSQL-compatible operational (OLTP) database — the row-oriented, application-facing system that applications and AI agents read from and write to.

How is LTAP different from HTAP?

HTAP serves transactional and analytical queries from a single engine, which couples storage and compute. LTAP unifies the two workloads at the storage layer and uses purpose-built engines for each, over one logical copy of data.

What makes Lakebase "lakehouse-connected"?

Lakebase data can be registered in Unity Catalog and served through synced tables, so operational data is governed and available for lakehouse analytics without separate copy pipelines or application changes.

Does adopting LTAP require migrating my database?

No. Lakebase remains standard Postgres; existing extensions, indexes, queries, and application code continue to work, and no data migration is required.