ClickHouse sells Postgres now: the other way to get both engines
Short version: ClickHouse Managed Postgres is a good product priced as one line item on a usage-metered ClickHouse Cloud bill, with a 50% beta discount and two meters that have not switched on yet. Layerbase runs Postgres free and ClickHouse on a flat $15/mo Pro plan, on one account with 16 other engines. Buy theirs if native CDC from Postgres into ClickHouse is the point of the system, because that is the thing we do not offer and you would otherwise build.
ClickHouse, the company best known for the fastest open-source OLAP engine in the business, now sells you Postgres. They announced the service in January and opened a public beta in May, built in partnership with Ubicloud, whose team came out of Citus Data and Heroku.
The reasoning is easy to follow. ClickHouse bought PeerDB in 2024 to move Postgres data into ClickHouse, discovered that nearly every analytics customer already had a Postgres sitting upstream, and decided to sell that half too. Transactions in Postgres, analytics in ClickHouse, one vendor, one console, CDC in between.
It is a good product and the strategy is sound. It is also not the only way to end up holding both engines, and if you are a small team the other way is considerably cheaper. That is the comparison this post is about.
What ClickHouse actually shipped
Credit where it is due, because the spec sheet is not thin:
- Postgres on local NVMe storage rather than network-attached disks, which is where the "up to 10x faster for disk-bound workloads" claim comes from
- High availability with up to two standbys, plus read replicas for read-heavy workloads
- 90+ Postgres extensions, point-in-time recovery, and database branching
- Native CDC into ClickHouse via ClickPipes, and the
pg_clickhouseextension for querying ClickHouse tables from Postgres, both included at no extra cost during the beta - Private Link, integrated monitoring, and Query Insights
- Configurations from 1 vCPU / 8 GB RAM / 59 GB NVMe up to 96 vCPUs / 768 GB RAM / 60 TB
They have kept shipping, too. An August update added disk-usage notifications at 85%, a searchable logs view, a Prometheus-compatible /metrics endpoint, faster wal-g backups, and pg_re2 for faster regular expressions.
If your problem is "I have a large Postgres and I want real-time analytics over it without building a pipeline," this is a strong answer, and the rest of this post is not going to pretend otherwise.
The price is a beta price
Here is the part worth reading the fine print on.
The entry configuration, 1 vCPU / 8 GB RAM / 59 GB NVMe, starts at roughly $32/month. That is already above what most small teams budget for a database, and it is not the steady-state number. From ClickHouse's own pricing docs:
- The service was free until usage metering began on June 15, 2026
- "All plans currently include 50% Beta pricing"
- "No charges currently apply for network egress or backups," and network egress pricing "will be introduced post-GA"
- "Additional backup charges may apply at GA for retention periods beyond a limit that is still being defined"
Those beta-pricing terms were re-verified 2026-08-26 from that same docs page: the 1 vCPU / 8 GB / 59 GB entry configuration, the 50% beta discount, the June 15 2026 metering start, and the post-GA egress and backup language are all still what it says. The ~$32/month figure is the exception. ClickHouse publishes a pricing calculator rather than a rate table for these configurations, so that number is the last one we confirmed and not a rate we re-fetched today; price your own configuration in their calculator before budgeting off it.
So three separate line items on that invoice are explicitly temporary: the discount, the egress, and the backups. None of that is hidden or dishonest, it is normal beta pricing and they wrote it down plainly. But if you are sizing a budget off today's number, you are sizing off a discount with a stated expiry and two meters that have not been switched on yet.
There is a fourth cost that is easy to miss: Managed Postgres lives inside ClickHouse Cloud. You are not buying a standalone Postgres, you are opening a ClickHouse Cloud organization. The Postgres line is priced off the VM configuration you choose, and it lands on an invoice next to ClickHouse's own metered compute and storage, with data transfer and backup charges joining it once those meters switch on. It is one line item on a usage-metered bill, not a standalone flat subscription.
What we do instead
Layerbase runs managed Postgres and managed ClickHouse as two engines in the same catalog, on the same login, on a flat monthly price.
Postgres is a Standard engine, which means it is on the free tier. $0, up to 2 databases, 5 GB of storage, up to 20 concurrent connections. It sleeps when idle and wakes on connect in a few seconds. There is no card, no trial clock, and no metering. Solo is $5/mo when you outgrow that.
ClickHouse is a Performance engine, which means it stays always-on and lives on Pro at $15/mo, with up to 10 databases across the whole catalog and $10/mo pool blocks if you need more always-on capacity. Pro is where you would land if you want both engines running at once, and $15 flat is roughly half the entry price of the ClickHouse Postgres box on its own, with ClickHouse itself included rather than metered next to it.
Durability on the Postgres side is no longer just the dump schedule. An always-on Postgres database on the Pro plan archives its write-ahead log continuously, so you can restore to any timestamp rather than to the last scheduled backup, and the restore lands in a new database instead of overwriting the one you are still trying to diagnose. The same switch covers FerretDB, because a FerretDB database here is Postgres underneath. How that was built and drilled is a post of its own.
The engines do not have to stop at two, either. Postgres and ClickHouse sit next to Redis, MySQL, DuckDB, FerretDB and the rest of an 18-engine cloud catalog on the same account and the same bill. If the third engine shows up in six months, it does not come with a third vendor.
Side by side
| ClickHouse Managed Postgres | Layerbase | |
|---|---|---|
| Postgres entry price | ~$32/mo at beta pricing | $0 on the free tier |
| ClickHouse | Metered separately in ClickHouse Cloud | Included on Pro, $15/mo flat |
| Billing model | Usage-metered, 50% beta discount, egress charges introduced post-GA, backup charges possible at GA | Flat monthly, no query or scan meter |
| Postgres to ClickHouse CDC | Native, via ClickPipes | Not offered, you wire it yourself |
| Unified query layer | pg_clickhouse | None |
| Postgres HA | Up to two standbys, read replicas | Single instance; 1 manual backup slot on Free, 7-day rolling on Solo, 30-day on Pro |
| Point-in-time recovery | Yes | Yes, on always-on Postgres and FerretDB on the Pro plan; restore to any timestamp, into a new database |
| Postgres branching | Yes | Yes, across 16 branchable engines; copy-on-write where the storage supports it |
| Top-end size | 96 vCPU / 768 GB / 60 TB | Pool blocks, then a dedicated server |
| Engines on the account | 2 | 18 |
What you give up by picking us
An honest comparison has to include this, and for some readers it is disqualifying:
- No managed CDC between our Postgres and our ClickHouse. ClickPipes is the single best reason to buy their version. If you want changes flowing from Postgres into ClickHouse continuously and you do not want to own that pipeline, they have built it and we have not. You would set up logical replication or a batch load yourself.
- No unified query layer.
pg_clickhouselets you query ClickHouse tables from inside Postgres. There is no equivalent here. Two engines means two connection strings. - No read replicas or standby HA on Postgres. You get a single instance, not a replicated cluster with failover, and the backup regime scales with the plan rather than being daily everywhere: one manual slot on Free, 7-day rolling on Solo, 30-day rolling on Pro.
- Nothing near 96 vCPUs. If your Postgres genuinely needs 768 GB of RAM, we are not the answer and you should stop reading comparison posts and go buy the big machine.
That list is the shape of the tradeoff: they sell an integrated analytics platform with Postgres attached, and integration is what you are paying the premium for.
When ClickHouse Managed Postgres is the right call
Buy theirs when analytics is the point of the system. You have real event volume, you want sub-second aggregates over transactional data, you want the replication managed, and you would rather pay for the pipeline than build it. Enterprise requirements like Private Link and two-standby HA push the same direction. At that scale the difference between $32 and $15 is noise and the CDC is worth real money.
When Layerbase is the right call
Pick us when you want the engines, not the platform.
You are a small team or a solo developer. You need a Postgres that costs nothing until it matters, and a ClickHouse for the dashboard you are building, and you would like both to appear on one invoice with a number you can predict a month in advance. You are not going to move 500 GB a day between them. You want to be able to leave with a pg_dump and a clickhouse-client dump rather than an unwinding project.
That is most people evaluating this, honestly. The unified real-time stack is a great pitch for the companies that need it, and a lot of teams reading the announcement do not need it yet, they just noticed they now need two databases and want to know what that costs. The answer, here, is $15 a month, and $0 if all you needed was the Postgres.
FAQ
Is ClickHouse Managed Postgres a standalone Postgres service?
No, and this is the detail most easily missed. It lives inside ClickHouse Cloud, so buying it means opening a ClickHouse Cloud organization. The Postgres line is priced off the VM configuration you pick and lands on an invoice next to ClickHouse's own metered compute and storage.
Will the beta price hold?
ClickHouse says plainly that it will not, which is to their credit. The docs state a 50% beta discount, no current charges for network egress or backups, egress pricing "introduced post-GA," and possible backup charges at GA for longer retention. Three line items on that bill are explicitly temporary.
What do I lose by running Postgres and ClickHouse on Layerbase instead?
Four things, and the first is the real one. There is no managed CDC between our Postgres and our ClickHouse, so a continuous pipeline is yours to build with logical replication or a batch load. There is no pg_clickhouse equivalent, so two engines means two connection strings. Postgres is a single instance rather than a replicated cluster with standbys and read replicas. And nothing here approaches 96 vCPUs.
What does running both engines actually cost here?
Postgres is a Standard engine, so it is on the free tier at $0. ClickHouse is a Performance engine, always-on, and lives on Pro at $15/mo, which also covers up to 10 databases across the whole catalog. If you need more always-on capacity than the included pool, capacity comes in $10/mo blocks.
Can I get my data out of either one?
Standard endpoints on both sides, so pg_dump and a clickhouse-client dump are the whole exit. That is deliberate: the reason to pick engines over a platform is that leaving is a command rather than a project.
Trying it
Create a Postgres database on the free tier and get a connection string in about a minute. If you want the analytics half too, create a managed ClickHouse on Pro and point clickhouse-client at it. Both are standard endpoints speaking standard protocols, so whatever you build on top stays portable.
I have run the fuller version of the pricing math before, and it lands the same way every time: a flat bill you can budget beats a metered one you reconcile after the fact, right up until the metered one is buying you something you genuinely cannot build. Native CDC into ClickHouse is one of the few things that qualifies. Two databases with predictable pricing is not.
Keep reading
- Preview environment platforms in 2026: what is in the database when the preview comes upEvery platform on this list will give a pull request its own URL. The question that sorts them is what is in the database behind that URL: nothing, a restore of last night's backup, or the live data as of right now. Here is where each of eleven platforms lands, quoted from their own docs, and what a preview costs while the PR sits open.
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.
- Layerbase vs Crunchy Bridge: two ways to buy managed PostgresCrunchy Bridge is Postgres specialists selling instance-hours across AWS, Azure and GCP. Layerbase is a flat monthly price, 18 engines and branching. A head-to-head on pricing, versions, extensions, HA, backups and placement, with worked examples.
- We put the Postgres write-ahead log on object storage. We did not put the database there.Databricks rebuilt Postgres so that object storage is the database. We shipped a much smaller thing: the write-ahead log leaves the box continuously, the live database stays on local disk. Here is the whole design, the two bugs that taught us the most, and an honest account of what this architecture does not buy.