The best Neon alternatives in 2026

Neon's architecture is the interesting part: storage is separated from compute, so a branch is a metadata operation rather than a copy, and an idle database can scale its compute to zero because the data isn't sitting on it. Branch-per-pull-request became a normal thing to do because of this design.

The same design produces the trade-offs people leave over. Here they are, and where each one goes. I build PandaStack, which runs managed Postgres on microVMs — a different point on the same spectrum, and I'll be specific about where it's the wrong answer.

The reasons people leave

1. Cold starts after idle

Scale-to-zero compute means the first query after an idle period waits for compute to come back. For a staging environment or an internal tool, this is a great deal. For a user-facing API with sporadic traffic — exactly the workload that idles — it's a latency spike on the request that mattered.

The mitigations are all forms of not idling: a minimum compute setting, a keepalive query, or accepting the spike. If your traffic pattern makes those unattractive, you want a database whose compute simply stays up, which is most of them.

2. Extensions and Postgres surface area

Every managed Postgres restricts extensions, and each provider's list is different. This bites specifically when you need something outside the common set — a custom C extension, a niche foreign data wrapper, an extension version newer than the provider offers, or anything requiring superuser.

If you need arbitrary extensions, the answer is a platform where the database is a machine you control rather than a service you're given: a dedicated Postgres instance, a VM you manage, or a managed offering built on per-database virtual machines. That's the category my product is in, and it's the one place I'd genuinely recommend it over Neon.

3. Cost at steady load

Usage-based database pricing wins for spiky and idle workloads and loses for consistent ones. A database busy around the clock on a compute-hour model is a variable-cost version of a fixed cost, without the predictability. If your compute never scales down because your traffic never stops, you're paying for the flexibility and not using it.

4. Latency and connection behaviour

Separating storage from compute adds a network hop on the paths where the compute node hasn't cached the pages it needs. For most workloads this is unnoticeable; for a query pattern that scans a lot of cold data, it isn't. Worth benchmarking your slowest real query rather than a synthetic one.

The options

• Supabase — Postgres plus auth, storage, and realtime. Right if you want the surrounding platform; more product than you need if you only want a database.
• Amazon RDS or Aurora — the boring, dependable answer. Extremely well understood, excellent operational tooling, no cold starts on provisioned instances. More setup, more knobs, and Aurora Serverless has its own scale-down behaviour worth reading closely.
• Crunchy Bridge, Timescale, and similar specialists — strong Postgres expertise, generous extension support, straightforward pricing. Good when you want Postgres taken seriously without running it yourself.
• PlanetScale — worth naming, but it's a different database lineage; treat a move there as a migration rather than a swap.
• PandaStack (mine) — each database is a Postgres instance on its own microVM with a durable volume, so compute stays up, the extension surface is the machine's rather than a provider allowlist, and clone-to-a-point-in-time creates an independent database from the archive. The trade is that provisioning a new database takes tens of seconds rather than being instant, because you're getting a machine.
• Self-managed Postgres on a VM — cheapest, most control, and you now own backups, failover, patching, and the 3am page. Legitimate if you have the on-call rotation already.

If you're leaving, don't lose branching

Branch-per-pull-request is the habit worth keeping. Once a team has a real database per preview environment, going back to a shared staging database that three people are mutating simultaneously feels awful.

Different platforms implement the equivalent differently — copy-on-write clones, restore-from-snapshot, or a scripted restore of a recent backup into a fresh instance. The properties to compare: how long it takes, whether it costs a full copy of storage, and whether the clone is genuinely independent so a destructive test can't touch production.

# A clone should be an independent database, not a view of production.
# Point-in-time clones make "restore to just before the bad migration"
# a normal operation rather than an incident.
pandastack db clone prod-db \
  --label pr-482 \
  --target-time 2026-08-18T09:15:00Z

# The source database is untouched; the clone gets its own id and URL

Migrating Postgres without losing data

1. Match the major version on the destination first. A version jump during a provider migration is two risky changes at once.
2. Check extensions on both sides before dumping anything. A restore that fails halfway on a missing extension is a bad way to learn.
3. Do a full dump-and-restore rehearsal into the new provider, timed, with the real data volume. The number you get is your maintenance window.
4. For anything where that window is too long, use logical replication to catch up, then cut over with a short pause on writes.
5. Keep the old database running and readable for at least a week. Not a snapshot — actually running.

The short version

Cold starts hurting user-facing traffic: a database whose compute stays up. Blocked by the extension allowlist: a database that's a machine you control. Steady load making usage pricing expensive: fixed-size provisioned instances. Wanting the surrounding platform: Supabase. And if branch-per-PR is the reason you're on Neon in the first place, make sure whatever you move to can do something equivalent — that's the feature you'll miss.