Crunchy Bridge alternatives: what the Snowflake acquisition did and did not change

Short version: Snowflake acquired Crunchy Data in June 2025, Snowflake Postgres went GA in February 2026, and Crunchy Bridge is still on sale today with open registration, a live pricing calculator, and current docs. Nobody has announced a sunset. If you are looking for a reason to move, the acquisition is not it. The billing model and the missing free tier might be.

This post is structured the way it is on purpose. The facts first, dated, so you can check them. Then what they imply and what they do not. Then the reasons to move that would be true if Snowflake had never called.

1. What was actually announced

Verified 2026-08-25, from Snowflake's own filings and Crunchy's own pages:

• Snowflake announced the acquisition of Crunchy Data on or about 2025-06-02.
• The deal closed 2025-06-06, for $164.5 million in cash, per Snowflake's FY2026 Form 10-K. Press coverage at the time widely reported a number closer to $250 million. The 10-K is the audited figure and the one worth citing.
• Snowflake Postgres, built on Crunchy technology, reached general availability on 2026-02-24.
• Crunchy's own acquisition announcement promises continuity for existing products and customers. It attaches no dates to that promise.

Now the part that matters more than any of the above, because it is what people get wrong in both directions.

None of the following has been announced: a sunset for Crunchy Bridge, a rename, a migration deadline, a forced move to Snowflake Postgres, or a wind-down of any kind.

Bridge is actively sold as of today. Registration is open to new customers. The pricing calculator is live and interactive. The docs are current, not archived. There is no banner on the site telling you anything is ending. I checked all of this before writing the sentence.

2. What that does and does not mean

What changed is who owns the roadmap. Before June 2025, Crunchy Bridge's product direction was set by a Postgres company whose entire business was Postgres. Now it is set inside Snowflake, whose Postgres strategy has a named flagship in Snowflake Postgres, and Bridge is one product in a much larger portfolio. That is not sinister. It is just a different decision-making structure, and product priority inside a large portfolio is not something a customer gets a vote on.

That is a reason to have a plan. It is not a reason to panic, and I want to be precise about the difference. Having a plan means knowing how you would get your data out, roughly how long it would take, and what it would cost, so that if an email ever does arrive you are executing rather than researching. That is good practice against every vendor including us.

Panicking means migrating a working production database because of a headline. Do not do that.

Anyone telling you Crunchy Bridge is dead is guessing. They may turn out to be right. Today they are guessing, and you should discount vendor content, ours included, that presents a guess as inside knowledge. The verifiable record is section 1 and it stops where section 1 stops.

3. Reasons to move that have nothing to do with the acquisition

These were all true in May 2025 and they are still true now.

There is no free tier. Every Crunchy Bridge cluster is a paid cluster, including the smallest Hobby one. I am not going to quote you a cheapest price, because their own pages currently show three different figures depending on where you look: a Hobby-0 monthly price, a "plans starting at" number, and a minimum-charge note attached to the trial. Pick your own reading; the part that holds under all of them is that there is no $0 option. For a side project, a prototype, or a database that exists so a CI job has something to connect to, that is the whole story.

Billing is per cluster. A cluster is the unit you buy and the unit you pay for, which means the shape of your bill follows the shape of your infrastructure. Two environments is two clusters. Three is three.

It is one engine. Crunchy Bridge is Postgres, and it is very good Postgres, and that is the entire catalog. That is a deliberate focus rather than a shortcoming, but it stops working for you the moment your stack grows a cache, a vector store, or a time-series database, because those come from somewhere else with their own account and their own invoice. Layerbase Cloud hosts 18 engines on one account and one bill.

A preview environment costs a second cluster. This is the one I would actually move over. If you want a copy of production data for a pull request, on Bridge that is another cluster: provisioned, restored into, and billed until you remember to delete it. Nobody does that per pull request, so in practice teams test against a seed script and hope.

On Layerbase, that is a branch. 16 of our Cloud engines branch copy-on-write, in seconds, out of your plan's branch allowance rather than out of your credit card. Postgres branches, obviously, since it is the engine most of this post is about. The workflow it unlocks is the reason to bother: branch production, point the preview deploy at the branch, delete it when the PR merges.

Prices for context, since I named the absence of a free tier: Layerbase Free is $0 with 2 databases and 5 GB, no card. Solo is $5/mo. Pro is $15/mo with up to 10 databases and 25 GB, and pool blocks add 1 GB of RAM, 1 vCPU, and 25 GB for $10/mo each when a database outgrows the plan. Flat monthly, no compute-hour meter.

4. What Crunchy is genuinely better at

This section is not a courtesy. If any of these describe you, the rest of the post does not apply.

High availability with a standby. Bridge offers a real HA configuration with a standby node. Layerbase does not offer a replica at any plan; every database we run is a single node with backups. If your recovery objective is measured in seconds, we are not the answer and I will not pretend otherwise.

Large single instances. Bridge scales up further than we do. If your working set needs a genuinely large box, they have one and we do not.

Per-minute scaling. You can resize a cluster and pay per minute for what you actually ran. For spiky or seasonal workloads that is a better economic model than any flat plan, ours included.

Fast Postgres major versions. Crunchy ships new Postgres majors quickly. If you want to be on the newest major shortly after it lands rather than months later, that is a real operational advantage.

Specialist Postgres support. You are talking to people who have contributed to Postgres and have run it at scale for other people for years. That is a different tier of support than most managed hosts, and it is worth money when something is genuinely wrong at 2am.

Crunchy Postgres for Kubernetes. If you are running Postgres in your own Kubernetes clusters, their operator is one of the best in the ecosystem, and it has nothing to do with Bridge or with us.

5. Moving the data

The Bridge side is straightforward. Each cluster's Connection tab lists a full URI per role: postgres, application, and a URI for each user you have created. The application role is not a superuser, which is worth knowing before you plan a dump, because ownership of objects created by other roles is exactly what a non-superuser export cannot faithfully reproduce. Hosts look like p.<cluster-id>.db.postgresbridge.com on port 5432. TLS is required regardless of your firewall settings, and only TLS 1.2 and 1.3 are accepted. The firewall itself ships open, 0.0.0.0/0 and ::/0, so in a default cluster there is nothing to allow first.

Paste a URI on the Crunchy Bridge migration page. We connect once, copy the schema and the data, and disconnect. Your cluster is read and never written to, and it keeps serving traffic while the copy runs. It is a single pass rather than continuous replication, so plan a cutover window rather than expecting to flip DNS whenever you feel like it.

Two things to check before you commit to a date. Extensions: list what you actually have installed with SELECT extname FROM pg_extension; and confirm the ones you depend on. And roles: if your application creates objects under multiple roles, decide who should own them on the other side before the copy, not after.

6. Deciding

The split is cleaner than most comparisons.

Move if you are running small to mid-size Postgres, you want a flat price instead of per-cluster billing, you would use a free tier for the environments that do not need to cost anything, you want previews to be a branch instead of a second cluster, or your stack has grown past Postgres and you would rather not collect another vendor.

Stay if you are running large HA production Postgres with a standby. Bridge does that and we do not, and that single fact outweighs everything in section 3. Stay too if per-minute scaling matches a spiky workload better than a flat plan, or if specialist Postgres support is load-bearing for your team.

Either way, revisit it. Not because anything is wrong, but because a roadmap that changed owners is worth checking on once or twice a year. Set a reminder for six months out and see whether Bridge's release notes still look like a product being invested in. That is a better signal than any acquisition rumor, and it is one you can read yourself.

FAQ

Is Crunchy Bridge shutting down?

Not per anything that has been announced. Verified 2026-08-25: no sunset, no rename, no migration deadline, and no wind-down has been announced, and Bridge is actively sold with open registration, a live pricing calculator, and current docs. Anyone who tells you otherwise is speculating.

What did Snowflake actually buy, and for how much?

Snowflake acquired Crunchy Data, announced on or about 2025-06-02 and closed 2025-06-06 for $164.5 million in cash per Snowflake's FY2026 Form 10-K. Press coverage widely reported roughly $250 million; the 10-K figure is the audited one.

What is Snowflake Postgres?

Snowflake's own Postgres offering, built on Crunchy technology, generally available since 2026-02-24. It is a separate product from Crunchy Bridge, and no one has announced that Bridge customers are required to move to it.

Does Crunchy Bridge have a free tier?

No. Every cluster is a paid cluster, the smallest Hobby one included. Their pages currently show more than one figure for the cheapest option, so check the calculator for your own case rather than trusting a number quoted in a blog post.

Can I run something other than Postgres on Crunchy Bridge?

No, and that is by design. Bridge is a Postgres product. If your stack has grown a cache, a vector store, or a time-series database, those live somewhere else. Layerbase Cloud hosts 18 engines on one account.

How do I get a copy of production for a preview environment?

On Bridge, by provisioning a second cluster and restoring into it, which is why most teams use a seed script instead. On Layerbase it is a branch: copy-on-write, seconds, and it comes out of your plan's branch allowance. 16 Cloud engines support branching.

Where is my Crunchy Bridge connection string?

On the cluster's Connection tab, which lists a URI per role: postgres, application, and one per user you have created. The host format is p.<cluster-id>.db.postgresbridge.com on port 5432, TLS is required regardless of firewall settings, and only TLS 1.2 and 1.3 are accepted.

Does moving to Layerbase mean losing high availability?

Yes, and it is the main thing you would give up. Bridge offers HA with a standby node. Layerbase databases are single node with backups, at every plan. If seconds of downtime is unacceptable, stay.

Starting

If you have a Bridge cluster, start at the Crunchy Bridge migration page with a URI from the Connection tab. The cluster keeps running while the copy happens.

If you are evaluating first, create a PostgreSQL database on the free tier and point a branch of your app at it for a week. Free is $0 with no card, which is the cheapest way to find out whether any of this argument holds for your workload.

The acquisition is a reason to know your exit. It is not, today, a reason to take it.