pgEdge Launches ColdFront Beta to Support AI Applications
2026-06-27 14:33
Favorite

en.Wedoany.com Reported - Distributed PostgreSQL provider pgEdge has launched the beta version of ColdFront, a PostgreSQL-native hot-cold data tiering architecture designed to automatically migrate older data to Apache Iceberg object storage while keeping PostgreSQL as the only database applications need to interact with.

For years, enterprises have typically maintained separate transaction processing (OLTP) and analytical (OLAP) systems, even if it meant moving data between the two. The rise of autonomous agents and AI applications, which require instant data access and generate massive amounts of operational data, has exposed the cost and complexity of maintaining independent systems. The industry has responded swiftly, with data warehouse and database vendors proposing various approaches to break down data silos: in recent weeks, Databricks launched LTAP, EDB introduced Converged Analytics, and late last year Snowflake released pg_lake, all offering different paths to integrate transactional, analytical, and AI workloads.

pgEdge's ColdFront employs hot-cold data tiering, where "hot" and "cold" refer to newer and older data respectively. According to Phillip Merrick, co-founder of pgEdge, queries for recent data still run on PostgreSQL, while requests for older records are transparently executed via DuckDB's embedded analytics engine, allowing applications to use the same SQL without introducing ETL pipelines, separate query paths, or application changes. Older records stored in Iceberg can also be updated through PostgreSQL, achieving what Merrick calls a "cold writable layer."

Ashish Chaturvedi, Executive Research Lead at HFS Research, noted that ColdFront treats Iceberg solely as a transparent storage layer behind PostgreSQL, automatically moving older data out of the database while allowing applications to use the same tables and SQL. In contrast, Databricks' LTAP connects operational applications to the lakehouse, EDB uses PostgreSQL as the operational data source and exposes data via Iceberg, and Snowflake's pg_lake writes PostgreSQL data directly to Iceberg, enabling both PostgreSQL and Snowflake to query the same data.

Amit Chandak, Chief Analytics Officer at IT consulting firm Kanerika, pointed out that enterprises need to retain historical operational data generated by AI applications for audit and regulatory purposes, so the ability to correct, delete, or modify records even after data has been moved to cheaper storage is crucial for compliance with data protection and privacy laws. Chaturvedi said ColdFront simplifies this process: "In most tiering systems, cold data is read-only, and GDPR deletion requests require restore-delete-rearchive, taking half a day; ColdFront allows UPDATE and DELETE of archived data rows with a single SQL statement." Igor Ikonnikov, Research Fellow at Info-Tech Research Group, noted that enterprises in finance, healthcare, and government want to keep sensitive operational data on customer-controlled infrastructure while retaining the ability to modify historical records, making ColdFront's architecture particularly important.

Ikonnikov noted that all solutions rely on DuckDB: "ColdFront uses DuckDB to execute queries on Iceberg data, Snowflake's pg_lake routes Iceberg queries through pgduck_server, and Databricks' Lakebase also internally depends on DuckDB. DuckDB is becoming the de facto embedded analytics engine for the new generation of PostgreSQL-Iceberg architectures." This dependency introduces a concentration risk: if DuckDB faces licensing changes, security vulnerabilities, or performance bottlenecks, the impact could ripple across multiple products. Therefore, CIOs should understand the maturity and roadmap of these shared components.

Michael Leone, Principal Analyst at Moor Insights & Strategy, believes most enterprises already have established data architectures, and CIOs should evaluate these platforms based on where their data, developers, and operational workflows reside. He recommends that enterprises first standardize on Iceberg, as all four architectures support the open table format, allowing enterprises to retain flexibility and replace front-end databases or analytics platforms in the future without migrating underlying data. Ikonnikov cautioned that Iceberg catalog governance poses challenges: the four approaches use different catalogs, and interoperability between vendors has not yet been resolved. When agents from different systems need to query the same Iceberg table, catalog federation becomes a practical challenge.

This article is compiled by Wedoany. All AI citations must indicate the source as "Wedoany". If there is any infringement or other issues, please notify us promptly, and we will modify or delete it accordingly. Email: news@wedoany.com