Postgres Vendors Take Different Routes to Merge Transactional and Analytical Data, and Analysts Point to a Shared DuckDB Dependency

Background

Separating transactional databases from analytical systems was long treated as sound architecture. InfoWorld reported in June that enterprises have kept the two apart for years, even when that meant moving data between them, and that the rise of autonomous agents and AI applications has exposed the cost and complexity of doing so. The Register describes the underlying difficulty: OLTP performs small, row-oriented reads and frequent writes, while OLAP performs large, column-oriented reads and batch writes, and getting the two to coexist in one system is hard at the physical level. The Register adds that the issue is seen as more pressing as the database market chases workloads created by the deployment of AI agents.

The idea is not new. The Register notes that SingleStore began work in 2014 on an in-memory row store paired with an on-disk column store, and lists MongoDB column-store indexes, Oracle’s HeatWave for MySQL and SAP’s HANA as other attempts to bring analytics and transactions together. What the sources describe in 2026 is a cluster of Postgres-centred designs that put open table formats such as Apache Iceberg on object storage behind or beside the database. This article compares those designs as reported by independent outlets and described by their vendors, and sets out what the sources say follows for developers.

Current situation

Competing blueprints

According to InfoWorld, data warehouse and database vendors have proposed a wave of competing approaches to collapsing these silos. HFS Research’s Ashish Chaturvedi, quoted by InfoWorld, summarised the differences: Databricks’ LTAP keeps operational applications connected to a lakehouse where analytics and AI are performed; EDB keeps PostgreSQL as the operational source of truth and exposes data through Iceberg to analytical engines; Snowflake’s pg_lake writes PostgreSQL data directly into Iceberg so that both PostgreSQL and Snowflake can query it; and pgEdge’s ColdFront treats Iceberg as a transparent storage tier behind PostgreSQL. InfoWorld refers to these as four architectures.

In an earlier InfoWorld report, EDB chief engineering officer Max Romanenko said “Databricks is building from the lakehouse outward, trying to pull transactional capability in through Lakebase,” while EDB builds from the operational layer. In the same article, HFS Research’s Chaturvedi said EDB’s per-core pricing model can make costs easier to forecast than consumption-based cloud data platforms.

pgEdge’s ColdFront, which InfoWorld reported had been introduced as a beta, is described there as a PostgreSQL-native hot-and-cold tiering architecture that automatically moves older data into object storage while keeping PostgreSQL as the only database applications need to interact with. pgEdge cofounder Phillip Merrick told InfoWorld that queries against recent data continue to run on PostgreSQL, while requests for older records are executed using DuckDB’s embedded analytical engine, which he called a “cold writable tier.”

AWS took a related route with Aurora PostgreSQL. According to the AWS News Blog (a vendor source), DuckDB is embedded directly within Aurora PostgreSQL so that live operational data, including uncommitted writes, can be queried alongside Iceberg and Parquet data in a single query. The feature supports Aurora PostgreSQL 17 (starting with 17.11) and 18 (starting with 18.6). As read on October 26, 2026, the post states it is available at no additional charge, with customers paying for incremental Aurora compute and S3 requests. The Herald covered the launch when it appeared.

Disagreement over “one copy”

The designs do not claim the same thing. The Register reports that Databricks marketed LTAP with the message “One data, zero compromises, zero copies,” and that its transactional side is Lakebase, a managed PostgreSQL service based on technology from Neon. According to The Register, a Databricks engineer acknowledged that there are technically two copies, since pageservers act as a cache or materialization layer, while a Databricks spokesperson said the user operates on one authoritative copy. SingleStore chief technology officer Nadeem Asghar, whose company The Register says began its own combined row and column design in 2014, responded that “Renaming it LTAP changes the marketing. It doesn’t change the physics, and it doesn’t retire the questions.” The Register also quotes Andy Pavlo, an associate professor at Carnegie Mellon University, as saying Databricks has done impressive engineering in how its Reyden engine reads PostgreSQL pages. The disagreement, as reported, concerns what counts as a copy rather than whether the engineering works.

A shared component

InfoWorld’s June report points to an overlap beneath the competing designs. Igor Ikonnikov of Info-Tech Research Group said that ColdFront uses DuckDB to execute queries against Iceberg data, that pg_lake routes Iceberg queries through pgduck_server, and that Databricks’ Lakebase relies on DuckDB internally for parts of its analytical processing. “DuckDB is rapidly becoming the de facto embedded analytics engine for this new generation of PostgreSQL-Iceberg architectures,” he said, and he described a resulting concentration risk. The AWS blog above describes Aurora’s embedded DuckDB as a further instance, published after InfoWorld’s comparison.

Ownership of the team behind that component changed hands in August. InfoWorld reported that AWS signed a definitive agreement to acquire DuckLabs, that the approximately 30-member team would join AWS once the acquisition closes, and that DuckDB would remain available under a permissive license. Chaturvedi told InfoWorld: “Developers shouldn’t mistake an unchanged license for an unchanged project.” The Herald covered the agreement when it was announced.

Other voices were more sanguine. In The Register’s coverage of an interview, AWS VP and Distinguished Engineer Andy Warfield said that half of DuckDB’s perceived value is as a “connective tissue layer across existing data processing tools.” Andy Pavlo, identified there as VP of Research at ClickHouse Labs and professor at Carnegie Mellon, said, “I don’t see them changing the long-term direction of the open source project.” MotherDuck co-founder Jordan Tigani, whose company sells a cloud service built on DuckDB, said, “Of course I’m nervous about the acquisition,” while also expecting the open-source project to move faster with added resources.

Agents as the stated driver

Nearly every source ties the shift to AI agents. The AWS blog says that the challenge of combining live and archived data “only grows as you increasingly embed AI agents into your applications.” A related pattern appears at the developer-environment level: The New Stack reported that pgEdge launched Starfleet, giving each coding agent its own Postgres branch. The Herald previously covered Databricks’ acquisition of Electric, another Postgres-for-agents move that sits outside the OLTP and OLAP comparison above.

Implications

The points below summarise what the cited sources say follows for developers and data teams. They are not forecasts by the Herald.

Application SQL may stay the same, but the tier boundary moves. AWS and pgEdge both describe designs in which existing PostgreSQL applications and tools keep working while older or lake-resident data is read through the database. In InfoWorld’s June report on EDB, IDC research director Devin Pratt is quoted saying that zero-ETL “means far less plumbing to build and break.”

Writable archives are presented as a differentiator in regulated settings. InfoWorld quotes Chaturvedi saying that in most tiering systems cold data is read-only, “so a GDPR deletion request on archived data means restore-delete-rearchive, which is a half day job.” He made the remark about ColdFront, whose vendor pgEdge is the party that benefits from the comparison, so it is one analyst’s reading rather than a measured result.

Catalogs are described as the unresolved layer. Ikonnikov told InfoWorld that all four approaches write to Iceberg but use different catalogs, and that “catalog federation becomes a real operational challenge” when agents from different systems query the same tables. Michael Leone of Moor Insights & Strategy recommended standardizing on Iceberg first, since all four support it, which would leave enterprises free to replace the front-end database or analytical platform later without migrating the underlying data.

A shared dependency concentrates risk and influence. Ikonnikov warned that a licensing, security, performance or governance problem in DuckDB would ripple across multiple products at once. After the DuckLabs agreement, Chaturvedi said that treating AWS as anything other than DuckDB’s de facto owner would be naive, while Pavlo and Tigani gave the more optimistic readings above. The sources agree the license is unchanged; they differ on whether roadmap influence follows employment.

Performance and cost claims are largely vendor-stated. The sources cited here do not include an independent benchmark comparing these designs. The cost figures that do appear in the sources, such as the per-core versus consumption-based pricing contrast, are analyst characterisations rather than measurements. The Register’s reporting on LTAP shows that even the term “copy” is contested.

Limits of the sources

Most analyst commentary comes from InfoWorld pieces written around product announcements, and several quoted parties (pgEdge, EDB, Databricks, SingleStore, MotherDuck, AWS) have commercial positions on the comparison. The Aurora feature postdates InfoWorld’s June comparison, and no cited independent outlet places it alongside the other designs. Availability and pricing statements reflect vendor pages as read on October 26, 2026.