For most of the last decade, data architecture diagrams had a hard line down the middle. On the left sat operational databases that ran applications: Postgres, MySQL, SQL Server, Oracle. On the right sat the analytical estate: a warehouse or, more recently, a lakehouse built on open table formats. Between them ran a tangle of extract jobs, CDC streams and reverse-ETL syncs whose only purpose was to move rows from one side to the other and, sometimes, back again.
In 2025 and 2026 that line started to blur in a very concrete way. The two largest lakehouse vendors both put managed Postgres inside their platforms, and an open-source extension now lets ordinary Postgres read and write Apache Iceberg tables directly. This article explains what has actually shipped, why it matters, where the hype outruns the reality, and how to decide whether operational Postgres belongs inside your lakehouse platform or should stay next to it.
What Actually Shipped: Three Moves Toward Convergence
It helps to separate the announcements, because they solve different problems and are at different stages of maturity.
Databricks Lakebase
Databricks announced general availability of Lakebase, its serverless managed Postgres service, on February 3, 2026, initially on AWS, with Azure in beta at the time. According to the Databricks GA announcement, Lakebase separates compute from storage, autoscales and scales to zero when idle, offers instant zero-copy branching of databases, point-in-time recovery, and “sync tables” that keep operational data aligned with lakehouse data without separately built pipelines. It supports Postgres 17 (with Postgres 16 still supported) and the pgvector extension, and it is governed through Unity Catalog. A separate Databricks post dated March 3, 2026 announced general availability on Azure Databricks, with Microsoft Entra ID integration, support for extensions such as pgvector and PostGIS, and the same branching and point-in-time recovery features.
Snowflake Postgres
Snowflake acquired Crunchy Data in June 2025 and announced Snowflake Postgres in public preview on December 17, 2025. The Snowflake engineering blog describes it as a fully managed, fully compatible Postgres (not a fork) running as dedicated instances with attached storage rather than as a virtual warehouse. The preview list includes built-in connection pooling, read replicas, point-in-time recovery, PrivateLink and customer-managed keys. Snowflake also said it is working on smoother data movement between Postgres and the rest of the Snowflake platform. Teams should check current availability in their region before planning production use.
pg_lake: open-source Postgres-to-Iceberg
On November 4, 2025, Snowflake open-sourced pg_lake under the Apache License, a set of Postgres extensions originally developed at Crunchy Data. According to Snowflake’s announcement, pg_lake lets you create Iceberg tables directly from Postgres with USING iceberg and full transactional semantics, query Parquet and CSV files in object storage as foreign tables, and use COPY to load data from or write results to S3. A later release, pg_lake 3.5 (September 2026), added a configurable Iceberg REST catalog endpoint and vended credentials, with read-write support for Apache Polaris and read-only support for Lakekeeper and Nessie; Unity Catalog support was described as planned. Because pg_lake is open source, it works with any Postgres you run yourself, not only Snowflake’s service.
Why This Is Happening Now
Vendors do not add a transactional database to an analytics platform on a whim. Three pressures pushed the market in this direction.
- AI agents need operational state. Agents and AI-powered applications need somewhere to store conversation memory, task state, feature values and embeddings with low-latency reads and writes. Both Databricks and Snowflake explicitly position their Postgres offerings for agent memory, vector search with pgvector and online feature serving.
- Data apps blur the line between OLTP and OLAP. Internal tools, embedded analytics and customer-facing dashboards often need to combine live transactional rows with historical context. Building those on two separately governed systems means two security models, two sets of credentials and a sync process in between.
- Open table formats made the storage layer shareable. Once Iceberg and Delta became the default storage for analytics, it became realistic for a database engine to write to the same files that the analytical engines read. pg_lake is the clearest example: Postgres becomes one more engine on the open lakehouse rather than a silo feeding it.
- Postgres won the developer mindshare contest. Postgres has become the default choice for new applications, which makes it the obvious operational engine for platform vendors to adopt rather than inventing a proprietary one.
Separating Signal From Hype
The marketing message is that you can “unify transactional and analytical workloads.” That is partly true and partly misleading, and getting the distinction right will save you from expensive architecture mistakes.
What genuinely gets better
- Fewer bespoke pipelines between app databases and the lakehouse when the vendor’s managed sync covers your case.
- One governance plane for access control and auditing across operational and analytical data, at least within a single vendor’s platform.
- Developer workflows such as zero-copy branching, which make it easier to test schema migrations and agent behavior against realistic data.
- Scale-to-zero economics for spiky or low-traffic internal apps and agent prototypes that would otherwise run on always-on database instances.
What does not magically change
- Postgres is still a row-oriented OLTP engine. Running heavy analytical scans against it, even when it is “in the lakehouse,” remains a poor idea; the point of the integration is to move data to the right engine cheaply, not to remove the need for one.
- Synchronization still has latency and failure modes. A managed sync is still a pipeline; you need to know its freshness guarantees, how it handles schema changes and what happens when it falls behind.
- Mission-critical systems of record have requirements (multi-region failover, specific compliance attestations, strict latency SLOs) that a new managed service may not yet meet. The Databricks GA post itself listed SOC 2 and HIPAA as on the roadmap at the time of announcement, so compliance status must be checked, not assumed.
- Vendor lock-in does not disappear; it moves. A platform-native Postgres tied to one vendor’s catalog and sync features can be harder to leave than a standalone database feeding an open lakehouse.
Treat lakehouse-native Postgres as a way to shorten the path between applications, agents and analytics, not as a reason to run analytics on a transactional engine or to move every system of record into your data platform.
Four Architecture Patterns and When Each Fits
In practice, organizations will mix these patterns. The useful question is which workload fits which pattern.
Pattern 1: Platform-native Postgres for data apps and agents
Use Lakebase or Snowflake Postgres for new workloads that are born close to the data platform: internal data apps, agent memory and state, online feature stores, and operational tables for ML-driven workflows. The benefit is a single governance and identity model and managed sync to analytical tables. The trade-off is tighter coupling to that platform.
Pattern 2: Standalone Postgres writing to open tables with pg_lake
Keep running Postgres where it runs today (self-managed, on a cloud managed service, or on Kubernetes) and use pg_lake to write selected tables or archives into Iceberg and to read lakehouse tables through a REST catalog. This pattern favors openness and portability, and it suits teams that have standardized on Iceberg with a catalog such as Apache Polaris. It requires more operational ownership and careful testing of extension compatibility with your managed Postgres provider, which may not allow custom extensions.
Pattern 3: Classic CDC into the lakehouse
For existing systems of record, especially large commercial databases or ERP back ends, log-based CDC into Iceberg or Delta remains the default. It decouples the operational system from the analytics platform and keeps the blast radius small. Nothing about the new offerings makes this pattern obsolete; they mainly reduce the number of new systems that need it.
Pattern 4: Analytical results served back to apps
The reverse direction matters too. Scores, segments and aggregates computed in the lakehouse often need to be served to applications with millisecond latency. Platform-native Postgres with synced tables can replace a separate reverse-ETL tool and key-value store for some of these cases, provided the freshness and throughput fit.
Decision Criteria: Should Operational Postgres Live in Your Lakehouse Platform?
Use the following questions to evaluate each candidate workload rather than making a platform-wide decision.
- Who owns the workload? If the data or AI team builds and runs it, platform-native Postgres is a natural fit. If an application team with its own release process and on-call rotation owns it, keep the database in their stack and integrate through CDC or pg_lake.
- How critical is it? Tier-1 systems of record need proven failover, documented RPO and RTO, and the compliance attestations your auditors expect. Confirm these for the specific service, region and cloud before committing.
- How much of its data does analytics need, and how fresh? If most tables feed analytics with minute-level freshness, managed sync is valuable. If analytics only needs a nightly extract of a few tables, the integration benefit is small.
- What are the access patterns? Bursty, intermittent or development workloads benefit from scale-to-zero. Steady, high-throughput transactional workloads may be cheaper on provisioned instances; model both.
- Which extensions do you need? Check that pgvector, PostGIS, pg_partman or any other extension you depend on is supported, and at which versions.
- How important is portability? If you are committed to an open Iceberg-first strategy with a neutral catalog, weigh pg_lake and standard CDC more heavily than proprietary sync features.
- What does identity look like? Platform-native Postgres inherits the platform’s identity and governance model. That is a benefit if you already govern data in Unity Catalog or Snowflake, and an integration task if your applications authenticate elsewhere.
A Practical Adoption Playbook
If the criteria point toward trying lakehouse-native Postgres, adopt it deliberately rather than migrating opportunistically.
- Inventory candidate workloads. List internal data apps, agent prototypes, feature stores and reverse-ETL destinations. Note owner, criticality, data volume, latency needs and current infrastructure.
- Pick one pilot with real users. An internal data app or an agent that needs persistent memory is ideal: valuable enough to matter, small enough to roll back.
- Define freshness and recovery targets up front. Write down acceptable sync lag between Postgres and analytical tables, plus RPO and RTO. Test them during the pilot by injecting load and failures.
- Design the data contract between engines. Decide which tables are authored in Postgres, which are authored in the lakehouse and synced back, and who may change schemas. Ambiguity here creates circular syncs and data quality incidents.
- Wire governance first. Map roles and groups, row-level policies and audit logging before loading production data, so the operational side is governed to the same standard as the analytical side.
- Use branching in CI. Make schema migrations and agent changes run against a short-lived branch of production data, with automated tests, before they touch the main database.
- Measure cost honestly. Track compute hours, storage, sync and egress for at least a full business cycle and compare with the previous architecture, including the pipelines you retired.
- Document exit paths. Know how you would move the database to standalone Postgres and the analytical tables to another engine if your strategy changes. Standard Postgres compatibility and open table formats keep this realistic.
Worked Example (Hypothetical)
Consider a hypothetical mid-sized logistics company that runs its analytics on a Databricks lakehouse and is building an AI agent to help dispatchers reassign delayed shipments. The agent needs to store conversation state and the decisions dispatchers accept or reject, look up live shipment status, and draw on historical lane performance computed in the lakehouse.
Under the old architecture, the team would have stood up a separate managed Postgres for agent state, a reverse-ETL job to push lane-performance aggregates into it, and a CDC pipeline to bring agent decisions back into the lakehouse for evaluation. That is three systems, three credentials and two pipelines to monitor.
With a lakehouse-native Postgres, the team stores agent memory and decisions in Postgres, uses synced tables to make lane-performance aggregates available for low-latency lookups, and lets decision records flow into the lakehouse for model evaluation, all governed in one catalog. Engineers test prompt and schema changes on database branches before release. Crucially, the company’s core transport management system stays where it is, feeding the lakehouse through existing CDC, because it is a tier-1 system owned by another team with its own resilience requirements. The new pattern is applied where it fits, not everywhere.
Pitfalls to Avoid
- Running reports on the operational engine. Just because the database sits inside the analytics platform does not make it an analytics engine. Route heavy queries to the lakehouse.
- Circular syncs. Syncing a table from Postgres to the lakehouse and a derived version back again without clear ownership creates loops and confusing lineage.
- Assuming feature parity across clouds. Availability, regions and features differ by cloud and change quickly. Verify each region you plan to use.
- Ignoring connection management. Agents and serverless apps can open many short-lived connections. Use pooling and test behavior when compute scales from zero.
- Skipping cost modeling. Scale-to-zero saves money for spiky loads; it does not guarantee savings for steady, heavy ones.
Outlook: 2027 and Beyond
Expect the convergence to continue along three lines. First, catalog interoperability: pg_lake’s roadmap already points toward broader REST catalog support, and the industry is moving toward engines of all kinds reading and writing the same governed Iceberg and Delta tables. Second, agent-centric features: memory, vector search and state management for agents will increasingly be treated as first-class platform services rather than add-ons. Third, competitive pressure from cloud providers’ own managed Postgres services, which are also adding lakehouse integration, will keep prices and features moving. Architects should expect to revisit these decisions annually rather than treat them as permanent.
Conclusion
Lakebase, Snowflake Postgres and pg_lake mark a real shift: operational Postgres is becoming a native citizen of the lakehouse rather than a distant source system. The biggest wins come for new data apps, AI agents and feature serving that live close to the data platform. Existing systems of record, heavy analytics and workloads with strict resilience or compliance needs still call for clear separation and well-run CDC. Evaluate workload by workload, pilot with explicit freshness and recovery targets, and keep open formats and standard Postgres compatibility at the center so your options stay open as the market keeps moving.
How Hanoi Technology Can Help
Hanoi Technology helps teams evaluate, pilot and integrate lakehouse-native Postgres, CDC and open table formats through projects, dedicated teams or managed services.
Further Reading
- Databricks Lakebase is Generally Available – Databricks
- Azure Databricks Lakebase is Generally Available – Databricks
- Snowflake Postgres is Now Available in Public Preview – Snowflake
- Introducing pg_lake: Integrate Your Data Lakehouse with Postgres – Snowflake
- pg_lake 3.5: Universal Iceberg REST Catalog Support for Postgres – Snowflake