pgEdge joins rush to merge OLTP and OLAP storage to support AI

For years, enterprises have maintained separate systems for processing data, even if that meant moving data between them. However, the rise of autonomous agents and AI applications needing immediate access to data while generating volumes of operational data themselves, has exposed the cost and complexity of maintaining those separate systems.

The industry’s response has been quick, with data warehouse and database vendors proposing a wave of competing approaches to collapsing those data silos. In the past few weeks Databricks unveiled , while late last year Snowflake launched provider pgEdge, which has introduced a beta version of object storage while keeping PostgreSQL as the only database that applications need to interact with.

In ColdFront’s architecture, hot and cold refer to newer and older data, respectively.

The approach of keeping PostgreSQL as the primary interface is what sets ColdFront apart from the other architectures emerging in this space, differing in where the center of gravity for data lies, according to analysts.

Databricks’ LTAP keeps operational applications connected to a lakehouse where analytics and AI are performed, EDB keeps PostgreSQL as the operational source of truth while exposing data through Iceberg for analytical engines, and Snowflake’s pg_lake writes PostgreSQL data directly into Iceberg so both PostgreSQL and Snowflake can query the same data, said , is that queries against recent data continue to run on PostgreSQL, while requests for older records are transparently executed using DuckDB’s embedded analytical engine, allowing applications to use the same SQL without introducing , chief analytics officer at IT consulting firm Kanerika.

ColdFront can simplify those processes, said Chaturvedi: “In most tiering systems, cold (older) data is read-only, so a GDPR deletion request on archived data means restore-delete-rearchive, which is a half day job. ColdFront’s architecture would allow you to UPDATE and DELETE archived rows through one SQL statement.”

The rival architectures make different tradeoffs, with Databricks asking enterprises to adopt a proprietary lakehouse as the operational center of gravity, Snowflake requiring applications to distinguish between PostgreSQL and analytical tables, and EDB still requiring archived data to be brought back into active PostgreSQL before it can be modified, he said.

Those tradeoffs are particularly significant for regulated industries, according to , principal analyst at Moor Insights & Strategy, arguing that CIOs should evaluate these platforms based on where their data, developers and operational workflows already reside rather than assuming one architecture fits every environment.

For enteprises still defining their long-term data strategy, Leone recommended standardizing on Iceberg first since all four architectures support the open table format and enterprises will retain the flexibility to replace the front-end database or analytical platform later without migrating the underlying data.

Even that portability, however, has limits, Ikonnikov cautioned.

“The issue is Iceberg catalog governance. All four approaches write to Iceberg, but they use different catalogs and their interoperability across vendors remains an open problem. When agents from different systems need to query the same Iceberg tables, catalog federation becomes a real operational challenge.”

This article first appeared on InfoWorld.