Layerbase vs Crunchy Bridge: two ways to buy managed Postgres

Short version: Crunchy Bridge sells you an instance. Layerbase sells you a plan. That is the whole difference, and almost every other disagreement between the two products falls out of it.

Crunchy Bridge is Postgres run by people who do Postgres for a living, priced the way cloud infrastructure is normally priced: pick a machine size, pay for it by the minute, pay ten cents a gigabyte for storage on top, put it in the AWS, Azure or GCP region you want. Layerbase Cloud is a flat monthly subscription that covers a pool of always-on capacity you spread across up to 18 engines, with branching, and no meter anywhere.

Neither model is wrong. They answer different questions. This post is about which question you are actually asking.

One thing out of the way first, because it is the reason most people arrive at this comparison: Snowflake acquired Crunchy Data in 2025, nothing about a Bridge sunset has been announced, and I wrote the dated version of that record in Crunchy Bridge alternatives. It is not part of this argument and I am not going to relitigate it here.

All Crunchy figures below were verified on 3 September 2026 from Crunchy's own pricing page and docs. All Layerbase figures come from our plan definitions in code.

Side by side

The pricing model is the whole argument

Crunchy publishes a clean price list. Hobby-0 is $9 a month for 2 cores and 0.5 GB of RAM, Hobby-2 is $35 for 1 core and 2 GB, Standard-8 is $140 for 2 cores and 8 GB, and it keeps going up to Memory-512 at $7,680. Storage is a separate line at $0.10 per gigabyte per month, and network transfer is included, which is genuinely nicer than most of the hyperscalers.

Billing is prorated to the second. If your workload is spiky or seasonal you can size up for a week and size back down, and you pay for the week. No flat plan can match that, ours included.

What the model costs you is predictability at the low end and a second bill for every environment. Here is the same requirement priced both ways.

A small production database. Say 2 GB of memory and 20 GB of data.

On Crunchy that is Hobby-2 at $35 a month plus $2 of storage, so $37. That cluster is burstable rather than dedicated vCPU, it does not include PgBouncer, it cannot have an HA standby, and it caps at 100 GB of storage. Step up to a Standard tier for any of those and the smallest one is $70 before storage.

On Layerbase, Pro is $15 a month and comes with a 1.5 GB always-on pool, 1 vCPU, 25 GB of storage, and room for up to 10 databases. Add one pool block at $10 a month and you have 2.5 GB always-on, 2 vCPU and 50 GB for $25 a month total, with pooled connections and client certificates included rather than tier-gated. If 768 MB is enough, Solo is $5. If the database can sleep between uses, Free is $0.

A step in between. The next example jumps straight to 8 GB, which skips the middle. If a workload needs its own always-on machine but nowhere near 8 GB, the dedicated 4 GB preset is 2 vCPU, 4 GB of memory and a 25 GB volume for $35 a month flat. That is the same $35 a month Crunchy charges for Hobby-2, which is 1 burstable core and 2 GB with a CPU baseline in the 5 to 20 percent range, no PgBouncer, no standby option and a 100 GB storage ceiling. Ours is a single-tenant machine rather than a burstable shared instance, and the 25 GB volume is included rather than billed at ten cents a gigabyte on top. The caveat is the one that runs through this whole post: it is still a single node with backups, so if you need a standby, $35 against $35 is not the comparison to make.

A mid-size production database. Say 8 GB of memory and 50 GB of data.

On Crunchy that is Standard-8 at $140 plus $5 of storage, so $145 a month for a single node. Turn on HA and the compute doubles to $280, and the 50 GB of storage lands on top: $285 a month if that storage is billed once, $290 if the standby's copy is billed separately. Crunchy does not publish whether the standby's storage is billed separately, so treat $285 as the floor and $290 as the case where it is.

On Layerbase that is the dedicated 8 GB preset: 4 vCPU, 8 GB of memory, a 50 GB volume, $65 a month flat, on a private single-tenant machine. It is a single node with backups. It has no standby, so it is not the same product as the $280 HA cluster, and I am not going to pretend it is.

The honest read is that at 8 GB single-node, we are less than half the price. At 8 GB with a standby, Crunchy is selling something we do not sell at any price. Those are both true at the same time and which one matters is a question about your recovery objective, not about money. I ran the general version of this math in the multi-database tax.

Postgres versions and extensions

Version support is close to a tie. Crunchy runs PostgreSQL 15 through 18, with 14 phasing out for existing customers and each major staying provisionable until six months before community end of life. We run 15 through 18 as well, default to 18, and also offer PostgreSQL 19 betas for anyone who wants to test against the next major early. What is new in PostgreSQL 18 covers what landed most recently.

Extensions are not a tie, and this is the clearest place where Crunchy is simply better. Their catalog runs to over a hundred extensions including PostGIS, TimescaleDB, Citus, pg_cron, pg_partman, pg_parquet for reading and writing Parquet in S3, and PL/Python and PL/R alongside PL/pgSQL. We ship the common ones, pgvector included, and we do not publish a catalog anywhere near that size.

So: if your schema depends on Citus sharding, TimescaleDB hypertables, or a PL/R function somebody wrote in 2019 that nobody wants to port, this comparison is over and Crunchy wins it. That is not a hedge, it is a real dependency and you should treat it as disqualifying.

High availability, and what we would not do

Crunchy's HA is a hidden hot standby the same size as your primary. On failure, their control plane promotes it, your connection string does not change, and every open connection is dropped and has to reconnect. That is a normal, well-built failover design, and it costs you double.

We do not offer a standby at any plan. Every Layerbase database is a single node with backups, and if your recovery objective is measured in seconds we are the wrong product.

Here is the thing we would not do: ship a replica flag that puts a second copy on the same physical host and call it high availability. That would demo well, price well, and fail in the exact circumstance the feature exists for. Until we can put a standby on separate hardware with failover we have actually drilled, the honest answer is that we do not have it, and a customer who needs it should buy it from someone who does.

Backups, PITR, and branching

On backups, Crunchy has the better default and I will say so plainly. Every cluster, including the $9 one, retains 10 days of backups at no extra charge, with WAL shipped every 60 seconds or 16 MB. Point-in-time recovery is therefore on for everybody inside a 10-day window, with no plan gate at all. Extended daily, weekly, monthly and yearly retention is configurable on top, though those extended backups restore to their completion time rather than to an arbitrary moment.

Ours is more tiered. Solo keeps 7 days of rolling daily backups and Pro keeps 30. Point-in-time restore is available on Pro and above, for PostgreSQL and FerretDB, and the database has to be pinned always-on because the recovery log needs a running instance to archive from. A restore produces a new database with its own connection string rather than overwriting the live one. The build story is in point-in-time restore on Postgres; current behavior is at /docs/cloud/point-in-time-restore.

Where we pull ahead is branching, and it is the feature I would actually switch for. 16 engines branch copy-on-write in seconds, Postgres included, out of the 18 in our cloud catalog. A branch is a full isolated copy of the data with its own connection string, and it comes out of your plan's branch allowance rather than your credit card: one per database on Free, three on Solo, ten on Pro.

On Crunchy, the nearest thing is forking a cluster from a backup. That works, it is well documented, and it is a second cluster billed by the minute from the moment it exists. Which is why nobody does it per pull request, and why most teams testing against Bridge are testing against a seed script instead of against real data.

Pooling, security, and placement

Both products give you PgBouncer-style transaction pooling. Crunchy runs it on production tiers and leaves it off Hobby, so the cheapest cluster is also the one that cannot pool. We issue a pooled and a direct endpoint for every Postgres database on every tier, including Free, and show both in the connect dialog. Free databases cap at 20 concurrent connections; paid ones do not.

One thing we have that Crunchy does not advertise is inbound client certificate authentication. On Pro and above, a Postgres database can require an mTLS client certificate in addition to a password, with a per-database certificate authority and one-click rotation. That is written up in Postgres mTLS client certificates.

Placement goes the other way, decisively. Crunchy deploys on AWS, Azure and GCP, so you can put the database in the same region as the rest of your infrastructure, match a data residency requirement, or keep an auditor happy. We run on our own hardware and you do not choose a cloud or a region. If placement is a requirement rather than a preference, that is another disqualifying difference.

Moving, if you are moving

The migration path is one pass. Open your cluster in the Crunchy dashboard, go to the Connection tab, and copy the URI for the postgres role. The application role also works but is not a superuser, so it is the wrong pick if your schema has extensions or objects that role does not own. Paste it on the Crunchy Bridge migration page.

We connect once over TLS, copy the schema and data, and disconnect. Your cluster is read and never written to, and it keeps serving traffic the whole time. Keep sslmode at require. That encrypts the copy in transit but does not validate the server certificate or the hostname, so it is not a defense against an active man-in-the-middle; verify-full with Crunchy's CA file would be, but the importer does not accept a CA file, so certificate identity is not validated for this copy. A default Bridge cluster ships with open firewall rules, so there is usually nothing to allow first.

It is a one-shot copy, not replication, so plan a cutover window. Before you pick a date, run SELECT extname FROM pg_extension; and confirm every extension you actually depend on exists on the other side. That check is one of the main risks, not the only one: the other two are the writes that land after the copy starts, which is what the cutover window exists to absorb, and any version-specific behavior change if you are not landing on the same Postgres major.

Who should pick which

Pick Crunchy Bridge if you need a hot standby, if you need to place the database in a specific cloud and region, if you depend on an extension outside the common set, if your instance needs to be genuinely large, if per-minute resizing matches a spiky workload better than a flat plan, or if you want a support contract with people who have contributed to Postgres itself. Every one of those is a real reason and none of them is a consolation prize.

Pick Layerbase if you are running small to mid-size Postgres and want a bill that does not move, if you want previews and CI to be branches instead of extra clusters, if you would use a free tier for the environments that should not cost anything, or if your stack has grown a cache, a search index or a vector store and you would rather not collect three more vendors. The engine-count argument is the one that compounds: 18 engines on one login and one invoice.

To test the argument rather than take my word for it, create a Postgres database on the free tier and point a branch of your app at it for a week. Free is $0 with no card. Plan details are on pricing, and the Aiven and Heroku Postgres writeups cover the same ground against other vendors.