Teams running Postgres in production keep telling me their databases never stop growing. Old data piles up that no one reads, and no one is allowed to delete it. pgEdge’s answer with ColdFront is to push that cold data down to cheap object storage, and the part I like is that it keeps it live and writable instead of freezing it. It’s a premise I’m buying. Storage bills climb on data that has gone quiet, and the usual fixes all make you give something up.

A writable cold tier is the part that makes this different

Tiering data by temperature is old. Hot, active records stay in fast Postgres storage, and older records you’re required to keep but rarely access get pushed to a cheaper storage option like S3. What pgEdge does differently is keep that cold data writable under the same table name, so an application keeps querying one table and never knows the older rows have been moved.

When it comes to tiering, the cold archive is almost always read-only. When you do need to reach back in, say to fix a record or run a deletion for compliance, you copy it to the hot tier, change it, and you end up paying for the round trip. ColdFront applies updates and deletes directly to the Iceberg copy, so old data behaves like the rest of the table. You pay for that on writes, though. One edit to a cold row can rewrite full Parquet files in object storage. A normal write avoids all that.

DuckDB inside Postgres turns the archive into something you can query

The analytics piece comes from DuckDB, which ColdFront runs inside the Postgres process itself. Queries against the cold Parquet data use a columnar engine built for that work, so they run fast without a separate analytics system. A team doing trend analysis or aggregations over years of history skips the ETL pipeline and the second platform that usually comes with it.

Let’s also be clear that running analytics inside the operational database isn’t new. HTAP was a niche idea a decade ago, largely because doing it well was slow and expensive. Object storage is cheap now, and a columnar engine like DuckDB can handle a heavy in-process scan without a separate service to run. It’s not that the database got smarter, but more that the tools and storage around it did. The catch is the shared process. A scan across years of history competes with live transactional work for the same CPU and memory, so cutting the second system puts more load on the one that’s left.

Open Iceberg turns storage into a hedge instead of a trap

ColdFront runs on stock community Postgres 16, 17, and 18, and it’s open source under the Postgres license. The important part is that the cold data lands in standard Apache Iceberg, not a pgEdge format. And with Iceberg turning into the common ground most engines read and write, anything parked there stays queryable by other tools and moves with you if you ever swap the database. That level of portability is a great value for a cold tier you might sit on for years.

It also works with pgEdge’s Spock replication, which keeps the cold data reachable for reads and writes from every node in a multi-master setup. The data itself stays portable, though only up to a point. You can take the Iceberg files with you, but the automation that tiered them and the in-process engine that makes them fast to query are pgEdge’s, so leaving means keeping the data and rebuilding the part that made it useful.

Where ColdFront leaves a small vendor in a crowded Postgres field

The whole field is chasing one governed copy of data for transactions, analytics, and AI. pgEdge can’t win that on breadth, and as a smaller open-source player, it shouldn’t try. Picking the writable cold tier as its sharp edge is the right call, and Postgres is the leverage, since anything that ships as a plain extension reaches the largest operational install base. The real contest runs upstream of other Postgres add-ons, over whether the operational database keeps its own queryable copy of history or ships it to a separate analytics platform, and a writable Iceberg tier is a small but real claim on that ground.

Consistency is the hard part of building this. You’ve got a hot Postgres tier and a cold Iceberg archive, and once both start accepting writes, keeping them in sync is what breaks down. Usually, it breaks late, under load, well after a quick test looks clean. pgEdge says it serializes writes with a commit protocol it ran through TLA+, and that’s the kind of thing I want a Postgres vendor to be reaching for. On the cost front, I’d set expectations based on the fact that while object storage is cheap, you’ll still likely pay some of it back in rewrites and in running a second engine. While tiering helps trim the storage bill, it doesn’t eliminate it. The real savings lie under the headline number. I like what pgEdge did anyway. A small player should pick one thing and do it well, and this is that. The timing helps too. Storage keeps taking a bigger slice of the database bill, and that’s exactly what ColdFront goes after.