Why look beyond Neon?
Neon did something genuinely clever: it separated Postgres storage from compute, added scale-to-zero, and made database branching feel as natural as a Git branch. For preview environments and bursty hobby workloads, that architecture is a great fit. After Databricks acquired Neon in 2025, a lot of teams started re-evaluating their data layer — not because Neon got worse, but because acquisitions tend to change roadmaps, pricing, and support priorities.
This post walks through the serverless and managed Postgres landscape in 2026. I run a developer cloud, so I'll be upfront about where PandaStack fits and where it doesn't — and I'll be fair to Neon, which remains a very good product.
What Neon does well (so you know what to replace)
- Instant branching of both schema and data, copy-on-write, near-zero cost per branch.
- Scale-to-zero compute — you pay near nothing when idle.
- Bottomless storage decoupled from compute.
- A clean, fast onboarding for serverless and edge runtimes via the Neon HTTP/serverless driver.
If those are the exact features keeping you on Neon, weigh that before switching. If instead you want predictable pricing, a database that lives next to your app, or an all-in-one platform, read on.
The main alternatives in 2026
| Platform | Model | Branching | Scale-to-zero | Best for |
|---|---|---|---|---|
| Supabase | Managed Postgres + BaaS | Yes (branching) | Limited | Teams wanting auth, storage, realtime bundled |
| Amazon Aurora Serverless v2 | Cloud-native Postgres | No native branch | Yes (min ACUs) | AWS-committed teams needing scale |
| Crunchy Bridge | Managed Postgres | No | No | Teams wanting plain, well-tuned Postgres |
| Timescale | Postgres + time-series | No | No | Time-series and analytics workloads |
| PandaStack | App platform + managed Postgres | No | App scales to zero | Teams wanting DB auto-wired to their app |
| Self-hosted (KubeBlocks/CloudNativePG) | DIY operator | Operator-dependent | Operator-dependent | Teams with platform engineers |
Supabase
Supabase is the most common destination for people leaving Neon, because it's also Postgres-first and adds auth, storage, realtime, and edge functions. If your app needs a backend-as-a-service and not just a database, Supabase is hard to beat. The trade-off: it's a larger surface area, and you're adopting a broader platform, not just a database.
Amazon Aurora Serverless v2
If you're already deep in AWS, Aurora Serverless v2 scales compute in fine-grained Aurora Capacity Units and can scale down to a small floor. It's the most battle-tested option at scale, but pricing complexity and the lack of Neon-style instant branching are real differences. See the AWS pricing page before committing.
Crunchy Bridge and Timescale
Both give you no-nonsense, expertly operated Postgres. Crunchy Bridge is great when you want "just Postgres, run well, with good support." Timescale is the choice when your workload is heavy on time-series, continuous aggregates, or compression.
Where PandaStack fits
PandaStack isn't a standalone serverless-Postgres product trying to out-branch Neon. It's an all-in-one developer cloud where the database is automatically wired to your application. When you connect a Git repo and deploy a container or buildpack app, PandaStack provisions a managed database and injects DATABASE_URL into your runtime — no copy-pasting connection strings.
We run managed PostgreSQL (14.x and 16.x), MySQL (5.7, 8.x), MongoDB, and Redis via KubeBlocks on GKE, with scheduled and manual backups. On the free tier you get one database, 7-day backup retention, and 50 connections; Pro and Premium raise connection limits (300 and 1000) and backup retention (15 and 30 days).
# A typical PandaStack app reads the injected URL directly:
# DATABASE_URL=postgres://user:pass@host:5432/dbname
psql "$DATABASE_URL" -c '\dt'Honest limits: our free-tier databases are sized for dev and hobby use (small storage), and we do not offer Neon-style copy-on-write data branching today. If branching is the single feature you depend on, Neon or Supabase branching will serve you better. If you'd rather your database and app live on one platform with the connection auto-managed, that's exactly our lane.
How to choose
- You love branching and scale-to-zero DB compute → stay on Neon, or evaluate Supabase branching.
- You're AWS-native and need scale → Aurora Serverless v2.
- You want plain, well-run Postgres → Crunchy Bridge.
- You want time-series superpowers → Timescale.
- You want the DB attached to your app with zero wiring → PandaStack.
A quick migration sanity check
Whatever you pick, do a pg_dump/pg_restore rehearsal before cutover and verify extensions:
pg_dump --no-owner --format=custom "$OLD_DATABASE_URL" -f dump.pgcustom
pg_restore --no-owner --dbname="$NEW_DATABASE_URL" dump.pgcustom
psql "$NEW_DATABASE_URL" -c 'SELECT extname FROM pg_extension;'Watch for extension parity (pgvector, PostGIS), default privileges, and connection-pooler behavior. Many "the new DB is slow" reports are actually a missing pooler or a mismatched max_connections.
References
- Neon documentation: https://neon.tech/docs
- Supabase database docs: https://supabase.com/docs/guides/database
- Amazon Aurora Serverless v2 pricing: https://aws.amazon.com/rds/aurora/pricing/
- Crunchy Bridge docs: https://docs.crunchybridge.com/
- Timescale docs: https://docs.timescale.com/
- KubeBlocks (open-source DB operator): https://kubeblocks.io/
---
If you want a managed Postgres that comes pre-wired to your app with DATABASE_URL injected automatically, PandaStack's free tier includes one database and a web service to put in front of it. Spin one up at https://dashboard.pandastack.io