Snowflake pg_lake versus Databricks LTAP: what is the difference?

Summary

• pg_lake is a set of open-source Postgres extensions (Apache 2.0) that Snowflake open-sourced in November 2025; it lets Postgres create and modify Iceberg tables and query, import and export data files in object storage.
• Databricks LTAP (Lake Transactional/Analytical Processing) is a data architecture that serves transactional and analytical workloads from one storage layer in the lake, on top of Lakebase, the Databricks Postgres database built on Neon technology.
• pg_lake keeps Postgres as the entry point and hands parts of query execution to DuckDB; in LTAP, Lakebase storage transcodes Postgres data into columnar Parquet that lakehouse engines read as Delta or Iceberg.
• In LTAP, Unity Catalog governs analytical access to registered Lakebase data, and standard Postgres privileges govern the transactional path.
• LTAP capabilities ship at different stages: Lakehouse//RT querying Lakebase is Beta and Lakebase Change Data Feed is in Public Preview. Registering Lakebase in Unity Catalog and synced tables are GA.

Snowflake pg_lake versus Databricks LTAP: what is the difference?

pg_lake brings lake formats into Postgres, and LTAP brings Postgres data into the lake. With pg_lake, a Postgres server creates Iceberg tables, reads and writes files in object storage, and hands parts of query execution to DuckDB. With LTAP, Lakebase storage writes a columnar copy of Postgres data into open formats as part of normal storage operation, so lakehouse engines can analyze it without a CDC pipeline.

What is pg_lake?

pg_lake "integrates Iceberg and data lake files into Postgres", according to its README. With the extensions installed, Postgres can:

• create and modify Iceberg tables with transactional guarantees, using CREATE TABLE ... USING iceberg, and query them from other engines
• query and import Parquet, CSV, JSON and Iceberg files in object storage, including through foreign tables
• export query results to object storage in Parquet, CSV or JSON with COPY

pg_lake delegates parts of query execution to DuckDB through pgduck_server, a separate multi-threaded process that standard Postgres clients can also connect to. The project started at Crunchy Data, which Snowflake acquired in June 2025, and Snowflake open-sourced it in November 2025.
In Snowflake Postgres, pg_lake moves data between Postgres and Snowflake. With shared Iceberg, Postgres acts as the Iceberg catalog and Snowflake reads the tables, read-only, through a catalog integration.

What is Databricks LTAP?

Lake Transactional/Analytical Processing (LTAP) is "a data architecture that serves both transactional (OLTP) and analytical (OLAP) workloads from a unified data storage layer in the lake, under one governance model". Databricks builds it on the Lakebase storage architecture: stateless Postgres compute over safekeepers, pageservers and cloud object storage.
As Lakebase storage materializes data into object storage, it transcodes row-oriented Postgres data into Parquet's columnar layout, readable through open table formats such as Delta and Iceberg. Transcoding runs in the storage layer, isolated from the primary Postgres instance. The docs name three pillars:

1. Universal governance: Unity Catalog governs analytical access to one logical copy of the data.
2. Purpose-built engines: Postgres serves transactions and the lakehouse serves analytics.
3. A single logical copy in open storage: both engines read one copy, with no replicas or pipelines to keep in sync.

Each table has a single writer, either Lakebase or the lakehouse. Applications that connect to Postgres are still governed by standard Postgres privileges (GRANT and REVOKE), not by Unity Catalog.

How do pg_lake and LTAP compare?

Dimension	Snowflake pg_lake	Databricks LTAP
What it is	Open-source Postgres extensions (Apache 2.0)	An architecture delivered through Lakebase capabilities
How lake data is produced	Postgres writes Iceberg tables and files to object storage	Lakebase storage transcodes Postgres data into Parquet, readable as Delta and Iceberg
Analytic execution	Parts of queries run in DuckDB through pgduck_server, on the same server machine	Lakehouse engines, such as Lakehouse//RT, read the columnar copy
Governance	Postgres manages its tables; Snowflake reads shared Iceberg tables through a catalog integration	Unity Catalog for analytical access; Postgres privileges for transactional access
Where it runs	Postgres built from source or in Docker, and Snowflake Postgres	Lakebase on Databricks; availability varies by cloud
Lifecycle	Open-sourced in November 2025	Each capability has its own stage (GA, Beta or Public Preview), varying by cloud

How does Databricks approach Postgres and lakehouse integration?

Lakebase is built on Neon technology and separates stateless Postgres compute from durable storage, and LTAP adds the columnar transcoding step to that storage layer. You adopt it through independent capabilities:

• Register Lakebase in Unity Catalog (GA): creates a read-only catalog with Unity Catalog permissions, lineage and audit.
• Synced tables (GA): serve Unity Catalog tables into Lakebase for low-latency reads, using managed Lakeflow pipelines.
• Lakehouse//RT querying Lakebase (Beta): transactionally consistent analytical queries on live Postgres data.
• Lakebase Change Data Feed (Public Preview): row-level changes stored as Unity Catalog Delta tables.

Pick by write direction. If your application writes to Lakebase, analyze those writes with Lakehouse//RT or stream them with Change Data Feed. If the lakehouse produces the data, serve it to applications with synced tables. Adopting LTAP doesn't require a data migration, because Lakebase remains standard Postgres.

FAQs

Is pg_lake open source?

Yes. pg_lake is published under Apache 2.0 at github.com/Snowflake-Labs/pg_lake. It began at Crunchy Data, which Snowflake acquired in June 2025, and Snowflake open-sourced it in November 2025.

Does LTAP need a CDC pipeline?

No. The docs say LTAP removes the need for a pipeline: Lakebase storage transcodes data into the lake as part of normal storage operation, with no external process polling your database.

Who governs access in each approach?

In LTAP, Unity Catalog governs analytical access to registered Lakebase data, and Postgres roles and privileges govern transactional access. In Snowflake Postgres, roles need USAGE on the catalog integration, plus standard Snowflake privileges, to create Iceberg tables over pg_lake data.