Christophe Pettus: Postgres Goes to the Lake, Two Ways

Why It Matters

The choice between pg_lake and Lakebase determines whether organizations can seamlessly blend existing OLTP workloads with analytics or need a unified lakehouse‑native Postgres, impacting cost, performance, and data governance.

Key Takeaways

• Snowflake's pg_lake reads Iceberg tables via a Postgres extension.
• Databricks' Lakebase runs serverless Postgres directly on lakehouse storage.
• pg_lake suits existing OLTP Postgres needing federated analytics queries.
• Lakebase fits use cases requiring operational data and analytics in one system.
• Decision hinges on architecture, not on marketing or vendor preference.

Pulse Analysis

Snowflake’s pg_lake represents a pragmatic approach for enterprises that already run PostgreSQL for transactional workloads and have a separate lakehouse for analytics. By exposing Iceberg tables through a foreign‑data‑wrapper‑like extension, pg_lake lets the PostgreSQL planner join OLTP tables with massive analytical datasets stored in S3, GCS, or Azure Blob. This federated model preserves traditional PostgreSQL transaction semantics while offloading heavy analytical scans to the lake, making it attractive for teams that want to keep their operational database unchanged and avoid data duplication.

Databricks’ Lakebase, built on the Neon architecture, takes a more radical stance: it embeds a serverless PostgreSQL engine directly into the lakehouse storage layer. The separation of compute and storage, combined with copy‑on‑write branching, enables rapid provisioning of isolated environments for development, testing, or AI agents. Because both operational and analytical data share the same underlying object store, Lakebase eliminates the need for query‑time federation and can deliver lower latency for mixed‑workload queries. Recent enhancements, such as customer‑managed encryption keys, also push the service into enterprise‑grade compliance territory.

Choosing between the two hinges on architectural intent. Organizations with mature OLTP systems that merely need occasional analytical joins will find pg_lake’s lightweight extension a cost‑effective bridge. Conversely, firms building new data products that require tight coupling of transactional and analytical workloads, or that benefit from branching and autoscaling, should consider Lakebase. Understanding these trade‑offs prevents costly mis‑alignments and ensures that the selected lakehouse strategy aligns with long‑term data governance and performance goals.