Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wczpL-003oF1-1l for pgsql-announce@arkaria.postgresql.org; Fri, 26 Jun 2026 06:14:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wczpK-009Izj-0W for pgsql-announce@arkaria.postgresql.org; Fri, 26 Jun 2026 06:14:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wczpJ-009IzX-1B for pgsql-announce@lists.postgresql.org; Fri, 26 Jun 2026 06:14:09 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wczpG-00000000JkZ-16OH for pgsql-announce@lists.postgresql.org; Fri, 26 Jun 2026 06:14:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:From:To:Subject: MIME-Version:Content-Type:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=14pTz9cKko9frae0NpmAST9DXNPCdG950tHYCFB/RGE=; b=PJHbAKJyXu1qtEkvjyQNnOpIgl NJnb6m2okjkjb9yvl66PoPp7QPQDkZg2JFlXNwPenN6gApMBBzJ1PplF7l82IZk7Uo8mpUxVvf85Q s/OELZrgNTatPQe3hY5mF326uzHtEQtEKQwkgnIYfPlrWpTs7rpDp0gJqaNjJZ6invrd5c/CeAru+ MQOSdefIx81HvdVa4C68ZZTDoemV0qxdQNvBdl5KRPlU+wXccj32Kze0h0jataPucSkTGDrt/jQpN 0arkbl2TeJ/T3eBaq9SFXZaGeXk3kJAvcaFMRU2M3EPdajPfXtitwKW9/FsyFa4qVkn/ycI+EXr2m I+aA4W3A==; Received: from wrigleys.postgresql.org ([217.196.149.60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wczpE-006h0t-2s for pgsql-announce@lists.postgresql.org; Fri, 26 Jun 2026 06:14:05 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wczpC-002K7X-3C for pgsql-announce@lists.postgresql.org; Fri, 26 Jun 2026 06:14:02 +0000 Content-Type: multipart/alternative; boundary="===============7392379461132001714==" MIME-Version: 1.0 Subject: pgEdge Announces ColdFront for PostgreSQL, Seamlessly Uniting AI, Analytical and OLTP Workloads To: PostgreSQL Announce From: "pgEdge, Inc. via PostgreSQL Announce" Reply-To: cto@pgedge.com Date: Fri, 26 Jun 2026 06:13:14 +0000 Message-ID: <178245439471.108996.8589178716216961484@wrigleys.postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-pglister-tags: related X-pglister-tagsig: 42f9b88e2abcd1fb99b508cd1b2d69f056bea7c4d6714c39afff7f8a27096828 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --===============7392379461132001714== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Offers read and write access to hot and cold storage with no application co= de changes, delivering up to 90% savings in storage ALEXANDRIA, Va., June 18, 2026 =E2=80=94 pgEdge, the leading open source en= terprise Postgres company, today announced pgEdge ColdFront, a transparent = data tiering solution for PostgreSQL. Unlike other alternatives, ColdFront= =E2=80=99s cold tier is fully writable: UPDATE and DELETE work on archived = rows through the same SQL the application already uses, with no code change= s and no rehydration required. Older data moves automatically to Apache Ice= berg in Parquet format on any S3-compatible object store at up to 90% lower= storage cost. Meanwhile the complete dataset stays readable and writable t= hrough a single Postgres table name, and cold-tier scans operate at analyti= cal speed thanks to the DuckDB vectorized columnar engine. Every useful production PostgreSQL database grows over time with historical= data required for analytical workloads and data retention requirements. St= orage costs and operational complexity including backups, vacuum overhead a= nd replica lag increase dramatically, all while the current data needed for= live operational OLTP applications remains relatively small. Teams respond= by deleting old data, archiving to flat files that break queries, or adopt= ing proprietary tiering solutions locking them into a vendor format for the= life of the data. pgEdge ColdFront eliminates the need to make these trade= -offs. Cold data moves automatically to cheap object storage, stays fully r= eadable and writable via standard Postgres, and is stored in an open format= at every layer. A simple yet problematic example demonstrates the power and convenience of = ColdFront: a GDPR deletion request against five-year-old archived data. Wit= h ColdFront this is a single SQL statement =E2=80=94 not a restore-to-hot, = delete, re-archive, and re-verify cycle. The cold tier is writable by defau= lt. =E2=80=9CFor years vendors have been claiming they=E2=80=99ve seamlessly un= ited analytical, transactional and now AI workloads. ColdFront finally deli= vers for Postgres, without trade-offs and without proprietary vendor lock-i= n=E2=80=9D, said Phillip Merrick, CPO of pgEdge. =E2=80=9CColdFront elimina= tes the trade-offs entirely. The application keeps the same SQL. DuckDB run= s in-process for analytical speed on cold data. The cold tier is writable. = And it runs on standard unpatched PostgreSQL, so no migrations are required= to deploy it.=E2=80=9D What Sets ColdFront Apart The only directly writable cold tier. Most tiering solutions make archived = data read-only, or require different code to write it. ColdFront=E2=80=99s = cold tier is fully writable through the same Postgres table name without re= hydration, special paths, or any application-level awareness of where data = resides. Analytical speed on cold data. ColdFront runs DuckDB inside the PostgreSQL = process, with no separate daemon or sidecar. Cold-tier scans on Parquet dat= a use DuckDB=E2=80=99s vectorized columnar engine, delivering 10-100x faste= r analytical performance than row-based storage on the same data. No ETL pi= peline, no second system, no CDC process required. Zero application changes. ColdFront intercepts SQL at the extension layer. = Applications continue using SELECT, INSERT, UPDATE, and DELETE against the = same table name. No refactoring, no ORM changes, no new data access pattern= s. The tiering is a property of the deployment, not the application=E2=80= =99s SQL. Fully open source at every layer. ColdFront runs on stock upstream PostgreS= QL 16, 17, and 18, not a proprietary fork. Cold-tier data is standard Apach= e Iceberg (Parquet on S3), readable by Spark, Trino, DuckDB, Snowflake, or = Databricks with no ColdFront dependency. If you stop using ColdFront, your = hot data is still a PostgreSQL table and your cold data is still standard I= ceberg files on S3. pg_dump, backups, logical replication, and existing ope= rational tooling work unchanged. Built-in partition lifecycle management. The working set of hot data is con= trolled with one single configuration parameter hot_period. An optional add= itional parameter retention_period can be used to automatically drop cold d= ata after the specified time period. ColdFront pre-creates future partition= s ahead of writes and retires old ones with DETACH CONCURRENTLY on stock Po= stgreSQL =E2=80=94 no blocking DROP, no manual intervention. It works stand= alone as a pure partition manager with no cold tier required, and tables ca= n be upgraded to full tiering later without re-modeling. Up to 90% storage cost reduction and less complex operations for cold data.= S3 object storage costs roughly 90% less than SSD-backed PostgreSQL storag= e. Smaller hot-tier databases also mean faster backups, faster restores, lo= wer replica overhead, and reduced managed-service bills. Naturally distributed via Spock. In a pgEdge Spock multi-master cluster, co= ld data on S3 is accessible for reads and writes from every node simultaneo= usly, providing a compelling scaling solution for workloads that require ei= ther extremely high throughput or high availability. Hot data replicates vi= a Spock; cold data lives in shared object storage, so clusters replicate on= ly the working set and query the full history from any node. The bakery pro= tocol, formally verified in TLA+, serializes Iceberg commits across nodes w= ith no 409 conflicts and no application-level retry; validated throughput a= t 4.4M rows per second across a 6-node mesh with 60 million rows. =E2=80=9CDatabase teams are paying SSD prices for data they almost never to= uch, while spending real engineering time managing what to keep, what to de= lete, and how to recover old data when the business needs it,=E2=80=9D said= Dave Page, CTO of pgEdge. =E2=80=9CColdFront handles the full lifecycle au= tomatically. The application keeps using the same SQL and the storage bill = drops by up to 90 percent. We validated it at 4.4 million rows per second a= cross a six-node cluster with 60 million rows. That is what production actu= ally looks like.=E2=80=9D AI-Ready Data Infrastructure AI and ML pipelines need access to the full depth of an organization=E2=80= =99s data, not just the recent working set. Training runs, RAG retrieval, f= eature engineering, and agentic analytics all query historical data that tr= aditional PostgreSQL deployments either delete or archive to inaccessible f= ormats. In decoupled mode, ColdFront turns PostgreSQL into a stateless compute fron= t-end over Iceberg: new compute nodes spin up against the same catalog and = object store in seconds with no data sync required. AI agents and ML pipeli= nes connect via standard PostgreSQL drivers and query terabytes of history = without a separate system. Combined with the pgEdge Agentic AI Toolkit =E2= =80=94 MCP Server, RAG Server, Vectorizer, and Docloader =E2=80=94 ColdFron= t provides a complete data backbone for agentic AI in regulated environment= s where data sovereignty is not optional. Who or What Benefits? SaaS and IoT time-series workloads. Applications generating millions of eve= nts per day keep the recent working set in PostgreSQL for dashboard and ale= rting queries. The archiver automatically moves older partitions to Iceberg= . Storage costs drop up to 90%; historical trend queries span both tiers th= rough the same SQL with no changes to the application. Regulated industries with long retention mandates. Financial services, heal= thcare, and government teams with 7-10 year retention requirements store co= ld data in Apache Iceberg, an open vendor-neutral format that remains reada= ble by any Iceberg-capable tool regardless of future vendor decisions. Comp= liance queries and deletion requests run through the same SQL interface. Analytics without a dedicated data warehouse. Product and BI teams run aggr= egations, cohort analysis, and trend queries over cold Parquet data using D= uckDB=E2=80=99s columnar engine running in-process inside PostgreSQL. No mo= re massive data warehouse vendor bills and no ETL pipeline, no CDC, no sepa= rate analytics system to build or maintain. Three Operating Modes ColdFront supports three storage modes plus a standalone partition manager,= configurable per table, all coexisting in the same database: Tiered (hot + cold): Recent data stays in PostgreSQL heap partitions. A lig= htweight archiver moves older partitions to Iceberg on a configurable sched= ule and expires cold data past its retention period. Best for OLTP-heavy wo= rkloads with a strong recency pattern. Decoupled (Iceberg-only): The entire table lives in Iceberg from row one. P= ostgreSQL becomes a stateless compute front-end, enabling elastic compute s= caling for AI, ML, and analytic workloads without moving data to a separate= system. Partition-only (no cold tier): ColdFront manages a partitioned table=E2=80= =99s full lifecycle on stock PostgreSQL with no Iceberg required. Tables ca= n start here and be upgraded to full tiering later without re-modeling. Availability pgEdge ColdFront is available now as a beta release for pre-production test= ing and evaluation. Both tiered and decoupled modes work end-to-end across = a fully green CI matrix covering PostgreSQL 16, 17, and 18 in vanilla and m= ulti-master Spock mesh topologies, including physical standby reads. Storag= e types supported include S3-compatible, Google Cloud Storage, and Azure Bl= ob Storage (ADLS Gen2). ColdFront will be bundled with pgEdge Enterprise Postgres and integrated in= to pgEdge Cloud within H2 2026. ColdFront is open source under the PostgreSQL License and usable on standar= d community PostgreSQL. pgEdge Enterprise Postgres customers can (starting = today) make use of available pre-built tested binaries and 24x7 enterprise = support. Documentation, installation instructions, and reference architectu= res are available at https://docs.pgedge.com/coldfront. To learn more or get started, visit https://github.com/pgEdge/coldfront. --===============7392379461132001714== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable pgEdge Announces ColdFront for PostgreSQL, Seamlessly Uniting AI= , Analytical and OLTP Workloads
 

pgEdge Announces ColdFront for PostgreSQL, Seamlessly Uniting AI, Ana= lytical and OLTP Workloads

Offers read and write access to hot and col= d storage with no application code changes, delivering up to 90% savings in= storage

ALEXANDRIA, Va., June 18, 2026 =E2=80=94 pg= Edge, the leading open source enterprise Postgres company, today announced = pgEdge ColdFront, a transparent data tiering solution for PostgreSQL. Unlik= e other alternatives, ColdFront=E2=80=99s cold tier is fully writable: UPDA= TE and DELETE work on archived rows through the same SQL the application al= ready uses, with no code changes and no rehydration required. Older data mo= ves automatically to Apache Iceberg in Parquet format on any S3-compatible = object store at up to 90% lower storage cost. Meanwhile the complete datase= t stays readable and writable through a single Postgres table name, and col= d-tier scans operate at analytical speed thanks to the DuckDB vectorized co= lumnar engine.

Every useful production PostgreSQL database= grows over time with historical data required for analytical workloads and= data retention requirements. Storage costs and operational complexity incl= uding backups, vacuum overhead and replica lag increase dramatically, all w= hile the current data needed for live operational OLTP applications remains= relatively small. Teams respond by deleting old data, archiving to flat fi= les that break queries, or adopting proprietary tiering solutions locking t= hem into a vendor format for the life of the data. pgEdge ColdFront elimina= tes the need to make these trade-offs. Cold data moves automatically to che= ap object storage, stays fully readable and writable via standard Postgres,= and is stored in an open format at every layer.

A simple yet problematic example demonstrat= es the power and convenience of ColdFront: a GDPR deletion request against = five-year-old archived data. With ColdFront this is a single SQL statement = =E2=80=94 not a restore-to-hot, delete, re-archive, and re-verify cycle. Th= e cold tier is writable by default.

=E2=80=9CFor years vendors have been claimi= ng they=E2=80=99ve seamlessly united analytical, transactional and now AI w= orkloads. ColdFront finally delivers for Postgres, without trade-offs and w= ithout proprietary vendor lock-in=E2=80=9D, said Phillip Merrick, CPO of pg= Edge. =E2=80=9CColdFront eliminates the trade-offs entirely. The applicatio= n keeps the same SQL. DuckDB runs in-process for analytical speed on cold d= ata. The cold tier is writable. And it runs on standard unpatched PostgreSQ= L, so no migrations are required to deploy it.=E2=80=9D

What Sets ColdFront Apart The only directly writable cold tier. Most tiering solutions make archived = data read-only, or require different code to write it. ColdFront=E2=80=99s = cold tier is fully writable through the same Postgres table name without re= hydration, special paths, or any application-level awareness of where data = resides.

Analytical speed on cold data. ColdFront ru= ns DuckDB inside the PostgreSQL process, with no separate daemon or sidecar= . Cold-tier scans on Parquet data use DuckDB=E2=80=99s vectorized columnar = engine, delivering 10-100x faster analytical performance than row-based sto= rage on the same data. No ETL pipeline, no second system, no CDC process re= quired.

Zero application changes. ColdFront interce= pts SQL at the extension layer. Applications continue using SELECT, INSERT,= UPDATE, and DELETE against the same table name. No refactoring, no ORM cha= nges, no new data access patterns. The tiering is a property of the deploym= ent, not the application=E2=80=99s SQL.

Fully open source at every layer. ColdFront= runs on stock upstream PostgreSQL 16, 17, and 18, not a proprietary fork. = Cold-tier data is standard Apache Iceberg (Parquet on S3), readable by Spar= k, Trino, DuckDB, Snowflake, or Databricks with no ColdFront dependency. If= you stop using ColdFront, your hot data is still a PostgreSQL table and yo= ur cold data is still standard Iceberg files on S3. pg_dump, backups, logic= al replication, and existing operational tooling work unchanged.

Built-in partition lifecycle management. Th= e working set of hot data is controlled with one single configuration param= eter hot_period. An optional additional parameter retention_period can be u= sed to automatically drop cold data after the specified time period. ColdFr= ont pre-creates future partitions ahead of writes and retires old ones with= DETACH CONCURRENTLY on stock PostgreSQL =E2=80=94 no blocking DROP, no man= ual intervention. It works standalone as a pure partition manager with no c= old tier required, and tables can be upgraded to full tiering later without= re-modeling.

Up to 90% storage cost reduction and less c= omplex operations for cold data. S3 object storage costs roughly 90% less t= han SSD-backed PostgreSQL storage. Smaller hot-tier databases also mean fas= ter backups, faster restores, lower replica overhead, and reduced managed-s= ervice bills.

Naturally distributed via Spock. In a pgEdg= e Spock multi-master cluster, cold data on S3 is accessible for reads and w= rites from every node simultaneously, providing a compelling scaling soluti= on for workloads that require either extremely high throughput or high avai= lability. Hot data replicates via Spock; cold data lives in shared object s= torage, so clusters replicate only the working set and query the full histo= ry from any node. The bakery protocol, formally verified in TLA+, serialize= s Iceberg commits across nodes with no 409 conflicts and no application-lev= el retry; validated throughput at 4.4M rows per second across a 6-node mesh= with 60 million rows.

=E2=80=9CDatabase teams are paying SSD pric= es for data they almost never touch, while spending real engineering time m= anaging what to keep, what to delete, and how to recover old data when the = business needs it,=E2=80=9D said Dave Page, CTO of pgEdge. =E2=80=9CColdFro= nt handles the full lifecycle automatically. The application keeps using th= e same SQL and the storage bill drops by up to 90 percent. We validated it = at 4.4 million rows per second across a six-node cluster with 60 million ro= ws. That is what production actually looks like.=E2=80=9D

AI-Ready Data Infrastructure AI and ML pipelines need access to the full depth of an organization=E2=80= =99s data, not just the recent working set. Training runs, RAG retrieval, f= eature engineering, and agentic analytics all query historical data that tr= aditional PostgreSQL deployments either delete or archive to inaccessible f= ormats.

In decoupled mode, ColdFront turns PostgreS= QL into a stateless compute front-end over Iceberg: new compute nodes spin = up against the same catalog and object store in seconds with no data sync r= equired. AI agents and ML pipelines connect via standard PostgreSQL drivers= and query terabytes of history without a separate system. Combined with th= e pgEdge Agentic AI Toolkit =E2=80=94 MCP Server, RAG Server, Vectorizer, a= nd Docloader =E2=80=94 ColdFront provides a complete data backbone for agen= tic AI in regulated environments where data sovereignty is not optional.

Who or What Benefits? SaaS and IoT time-series workloads. Applications generating millions of eve= nts per day keep the recent working set in PostgreSQL for dashboard and ale= rting queries. The archiver automatically moves older partitions to Iceberg= . Storage costs drop up to 90%; historical trend queries span both tiers th= rough the same SQL with no changes to the application.

Regulated industries with long retention ma= ndates. Financial services, healthcare, and government teams with 7-10 year= retention requirements store cold data in Apache Iceberg, an open vendor-n= eutral format that remains readable by any Iceberg-capable tool regardless = of future vendor decisions. Compliance queries and deletion requests run th= rough the same SQL interface.

Analytics without a dedicated data warehous= e. Product and BI teams run aggregations, cohort analysis, and trend querie= s over cold Parquet data using DuckDB=E2=80=99s columnar engine running in-= process inside PostgreSQL. No more massive data warehouse vendor bills and = no ETL pipeline, no CDC, no separate analytics system to build or maintain.=

Three Operating Modes ColdFront supports three storage modes plus a standalone partition manager,= configurable per table, all coexisting in the same database:

Tiered (hot + cold): Recent data stays in P= ostgreSQL heap partitions. A lightweight archiver moves older partitions to= Iceberg on a configurable schedule and expires cold data past its retentio= n period. Best for OLTP-heavy workloads with a strong recency pattern.

Decoupled (Iceberg-only): The entire table = lives in Iceberg from row one. PostgreSQL becomes a stateless compute front= -end, enabling elastic compute scaling for AI, ML, and analytic workloads w= ithout moving data to a separate system.

Partition-only (no cold tier): ColdFront ma= nages a partitioned table=E2=80=99s full lifecycle on stock PostgreSQL with= no Iceberg required. Tables can start here and be upgraded to full tiering= later without re-modeling.

Availability pgEdge ColdFront is available now as a beta release for pre-production test= ing and evaluation. Both tiered and decoupled modes work end-to-end across = a fully green CI matrix covering PostgreSQL 16, 17, and 18 in vanilla and m= ulti-master Spock mesh topologies, including physical standby reads. Storag= e types supported include S3-compatible, Google Cloud Storage, and Azure Bl= ob Storage (ADLS Gen2).

ColdFront will be bundled with pgEdge Enter= prise Postgres and integrated into pgEdge Cloud within H2 2026.

ColdFront is open source under the PostgreS= QL License and usable on standard community PostgreSQL. pgEdge Enterprise P= ostgres customers can (starting today) make use of available pre-built test= ed binaries and 24x7 enterprise support. Documentation, installation instru= ctions, and reference architectures are available at https://docs.pgedge.co= m/coldfront.

To learn more or get started, visit https:/= /github.com/pgEdge/coldfront.
This email was sent to you from pgEdge, Inc.. It was delivered on their beh= alf by the PostgreSQL project. Any questions about the content of the message shou= ld be sent to pgEdge, Inc..

You were sent this email as a subscriber of the pgsql-announce mai= linglist, for the content tag Related Open Source. To unsubscribe from further emails, or change which emails you want to receive, please click th= e personal unsubscribe link that you can find in the headers of this email, or visit https://lists.postgresql.org/unsubscribe/.
 
--===============7392379461132001714==--