pgEdge ColdFront · Postgres tiered storage
Keep active data in Postgres and move older data to Apache Iceberg object storage. Query and update it all through the same SQL and same set of table names. All without any code changes or vendor lock-in.
lower storage cost for cold data
faster analytical queries on cold Parquet data
hot and cold tiers
application changes
ColdFront keeps active data in Postgres and moves older data to lower-cost Apache Iceberg storage. Applications query and update everything through the same table and standard SQL—without a separate warehouse, ETL pipeline, or read-only archive.
Update or delete historical data through the same table name—even after it moves to cold storage. A GDPR deletion request or data correction stays one SQL statement instead of becoming a restore, modify, re-archive, and re-verify project.
DuckDB runs inside the PostgreSQL process and scans cold Parquet data with a vectorized columnar engine. There is no separate analytical service, sidecar, or data-copy pipeline to manage.
ColdFront runs on stock PostgreSQL 16, 17, and 18. Keep your existing drivers, SQL, applications, tools, and operational practices.
Cold data is stored as Apache Iceberg and Parquet on S3-compatible object storage, Azure Blob Storage, or Google Cloud Storage. Any Iceberg-capable engine can read it without ColdFront in the path.
In a pgEdge Spock mesh, multiple nodes can write to shared Iceberg tables while ColdFront coordinates commits across the distributed environment.
ColdFront runs DuckDB in-process and uses a small, composable set of open components—without a separate compute cluster or sidecar fleet.
AI agents and ML pipelines need historical context, but keeping every record on SSD-backed PostgreSQL quickly becomes expensive. ColdFront keeps the full dataset queryable through Postgres while placing older data on lower-cost object storage. In decoupled mode, PostgreSQL becomes a stateless compute layer over Iceberg, so teams can query large histories with standard SQL and scale compute independently.
ColdFront fits applications with fast-growing Postgres tables, frequently accessed recent data, and historical data that must remain available.
Keep the latest events fast for dashboards and alerts while moving older history to lower-cost object storage for reporting and trend analysis.
Retain years of queryable data in an open format that remains accessible beyond any individual vendor relationship.
Apply GDPR, CCPA, and data-quality changes directly to archived records without rehydrating entire datasets.
Replicate the active working set with pgEdge Spock while making the full Iceberg history available to Postgres nodes across regions.
Give agents and ML pipelines SQL access to the complete data history while keeping storage and compute independently scalable.
Run aggregations and analytical queries across operational history without building and operating a separate CDC or ETL pipeline.
Choose the storage model per table. All three modes can coexist in the same database.
Keep recent partitions in native PostgreSQL for full OLTP performance. ColdFront moves older partitions to Iceberg on a configurable schedule and can expire data after its retention window.
Store the full table in Iceberg from the first row and use PostgreSQL as a stateless SQL compute layer. Scale compute independently against the same catalog and object storage without duplicating the dataset.
Automate partition creation and retirement on stock PostgreSQL without Iceberg. Add tiering later when the workload requires it.
ColdFront is built on standard, composable infrastructure so your data remains accessible with or without pgEdge.
Postgres tiered storage keeps frequently accessed data in native PostgreSQL while moving older or less frequently accessed data to lower-cost object storage. ColdFront presents both tiers through the same Postgres table name and SQL interface.
No. Your application continues to query and modify the same table with standard Postgres SQL. ColdFront handles whether each row lives in native PostgreSQL or Apache Iceberg.
No. ColdFront’s cold tier supports reads, updates, and deletes through the same table name. Historical corrections and right-to-delete requests do not require restoring the data to the hot tier first.
No. ColdFront runs on stock PostgreSQL 16, 17, and 18.
Cold data is stored in Apache Iceberg and Parquet on S3-compatible object storage, Azure Blob Storage, or Google Cloud Storage.
Yes. Because cold data uses standard Apache Iceberg and Parquet, it remains readable by Iceberg-compatible tools and engines without ColdFront in the query path.
ColdFront keeps the complete data history accessible through standard Postgres SQL while lowering the cost of storing older data. In decoupled mode, PostgreSQL can act as a stateless compute layer over Iceberg, allowing AI and ML workloads to query large histories without duplicating the dataset into a separate system.
Yes. ColdFront’s core extension and archiver are open source. An enterprise subscription adds tested packages, distributed capabilities, operational tooling, and 24x7x365 support.
