Serverless Postgres in 2026: Neon, Supabase, and the tradeoffs

Three products describe themselves as serverless Postgres and mean three different things by it. Neon means separated storage and compute with branching as the headline. Supabase means a whole backend that happens to be built on Postgres. ScalixNova, which is ours, means an engine we wrote from scratch that speaks the Postgres wire protocol.

Feature grids do not help much here, because the three are not competing on the same axis. What follows is what each actually does, taken from their own documentation and cited inline, and where the tradeoffs land.

What the label is supposed to mean

Strip the marketing and “serverless Postgres” is usually claiming three things.

Storage and compute are separated, so the component holding your data is not the component running queries. Idle databases suspend, so you are not paying for a server nobody is talking to. And billing follows usage instead of a provisioned box.

All three do some version of that. Everything built around it is where they part company.

Neon: branching as the organising idea

Neon’s branching docs are unambiguous about the mechanism. “A branch is a copy-on-write clone of your data.” Creating one copies nothing. A branch and its parent “share the same data but diverge at the point of branch creation”, writes to the branch “are saved as a delta”, and creating one “does not increase load on the parent branch or affect it in any way”.

That is the strongest branching mechanism of the three, and it is worth saying plainly rather than burying: ours works differently and is slower at the same job. More on that below.

What bounds Neon’s branching is the history window. Retention defaults to six hours on their entry plan and one day on paid plans, configurable up to seven days on Launch and thirty on Scale, with the tradeoff stated in their own docs: “Increasing the history window expands recovery options but also increases storage costs.” Branch expiry for temporary environments and schema-only branching for sensitive data are both documented features.

On coverage, Neon lists eight active AWS regions in their region docs: N. Virginia, Ohio, Oregon, Frankfurt, London, Singapore, Sydney and São Paulo. The Azure regions are marked deprecated and no longer accept new projects. A project’s region is fixed at creation, and their guidance if you picked wrong is blunt: “If you need your data in a different region, you create a new Neon project in that region and migrate your database there.”

The ownership question is worth naming because people ask. Databricks announced its acquisition of Neon on 14 May 2025, and the founders wrote that “Neon isn’t going anywhere, we’re doubling down”. Whether that reassures you depends entirely on how you feel about a database roadmap living inside a large data platform vendor. It is a fact to weigh, not a criticism.

Neon is deliberately database-only. Compute, object storage, auth and inference come from elsewhere in your stack, and that is the design rather than an omission.

Supabase: the database as a backend

Supabase is a different category wearing an overlapping label. The database is standard Postgres. The product is everything wrapped around it.

PostgREST generates a REST API directly from your schema. Supabase describe it as “a thin API layer on top of Postgres” whose interface is “automatically reflected from your database’s schema”, covering CRUD, views, materialized views, foreign tables, functions and computed columns, with every request resolving “to a single SQL statement leading to fast response times and high throughput”. Security runs through Postgres itself: the API is “configured to work with Postgres’s Row Level Security, provisioned behind an API gateway with key-auth enabled”. pg_graphql, listed in their own architecture README, adds a GraphQL API as a Postgres extension.

Realtime ships three distinct capabilities: Broadcast to “send low-latency messages between clients”, Presence to “track and synchronize user state across clients”, and Postgres Changes to “listen to database changes in real-time”.

And the stack is open source under Apache-2.0. The README lists the components: Postgres, Realtime, PostgREST, GoTrue, Storage, pg_graphql, postgres-meta and Envoy. Self-hosting is documented via Docker Compose, with community Helm charts and Traefik setups alongside it.

Those three things, the open core, realtime, and APIs generated from your schema, are genuine strengths, and we have none of them. If any one is load bearing in your architecture, this survey is short: Supabase is your answer and nothing below changes that.

The honest asterisk is on self-hosting, and Supabase state it themselves. A self-hosted deployment “runs as a single project which means that Studio doesn’t support multiple organizations or projects”, and branching, managed backups and PITR, advanced metrics, analytics and vector buckets, ETL and the platform management API are all listed as unavailable. Self-hosted is community supported. Provisioning, hardening, Postgres maintenance, high availability, backups and monitoring become yours. Open source removes vendor dependency. It does not remove the operations.

ScalixNova: what changes when you write the engine

Ours is the odd one out here, so the same treatment, gaps first where they matter.

ScalixNova is not managed upstream Postgres and it is not a fork. It is a purpose-built storage engine that speaks the PostgreSQL wire protocol. Storage and compute are separate components we wrote: a storage engine that materialises pages from the write ahead log, a WAL keeper providing term-fenced durable WAL storage, and a compute layer running PostgreSQL workers on the major you chose. It is designed from day one for Paxos-style quorum replication as we grow beyond one region, rather than replication bolted on afterwards. The durability half of that is worked through in how durability works in ScalixNova.

From your side of the socket, none of that is visible. A standard DSN, TLS required, psql and your ORM and your migration tool connect the way they always have.

You pick PostgreSQL 16, 17 or 18 at creation, and the major is fixed for the life of that database, inherited by every branch and every point in time restore. That pinning falls out of the architecture rather than being a limitation we chose to live with, and the reasoning is in Postgres 16, 17 and 18 on a serverless engine.

Branching is where writing your own engine currently costs us. A Scalix branch is restore-based: built from the parent’s backup to a chosen point in time, fully isolated, with its own scoped token and a TTL so scratch branches expire instead of accumulating. It carries real data, and it does the job well for handing an AI agent a database it is allowed to break, particularly over MCP. It is not a copy-on-write clone and we do not describe it as one. For large databases branched frequently, Neon’s mechanism is faster, and that gap is not closing this month.

Point in time recovery runs on the same machinery, bounded to five minutes while the database is active, with the open WAL segment shipped when it suspends. Compute is acquired per connection and released after, so a paused database does not meter compute.

Coverage is one region, in the EU, on dedicated hardware we operate, with India next. That is one against Neon’s eight and Supabase’s many.

What the from-scratch route buys is control of the paths that matter when something goes wrong: which binaries replay your WAL, what a restore does when you ask for a moment outside your retention window, how a branch is isolated from its parent. What it costs is that a two-person team carries correctness that upstream Postgres carries for everyone else, and that is a concentration risk you should price in rather than take on faith.

The four questions that actually decide it

How often do you branch, and how large is the database? If branching per pull request on a large database is the workflow, the mechanism matters more than anything else on this page, and Neon’s is the better one.

How much of the backend do you want from one vendor? Supabase gives you auth, storage, functions and realtime as a suite. Neon gives you a very good database and expects you to compose the rest. Scalix puts the database inside a platform where containers, functions, object storage, auth and inference sit behind the same key and the same usage ledger. These are three different answers to how many vendors you want to hold, not three quality levels.

Where does it run, and who operates it? Neon on AWS. Supabase hosted on major public cloud, or on your own Docker host if you self-host. Scalix on dedicated European hardware operated by European and Indian companies with no US parent. If data residency or operator sovereignty is driving the decision, that difference is the point. If region count is driving it, we lose.

Who owns the roadmap? Neon sits inside Databricks. Supabase’s core is Apache-2.0, so the worst case is that you run it yourself. Scalix is founder owned with a closed core, which means the incentives are ours and also that you could not fork us if we disappeared.

Getting out, which is worth checking before you get in

All three speak the standard Postgres wire protocol, so the database move is ordinary tooling: pg_dump and pg_restore over a TLS DSN, or logical replication for a shorter cutover. No proprietary format exists on any side of that.

The parts that do not move cleanly are the parts that are not Postgres. Supabase auth users and storage objects are application level migrations. Neon branch history does not transfer as branch history. Scalix branch and PITR windows stay behind. Plan for the database to be straightforward and the surrounding features to be work.

Where each is the right answer

Neon, if branching is the workflow rather than a feature you use twice a year, if you want a database-only vendor, or if you need a region we do not have.

Supabase, if realtime subscriptions or schema-generated APIs are load bearing, if an open core you can read and self-host is a requirement, or if you want the whole backend from one place with years of production history behind it.

ScalixNova, if you want serverless Postgres with the rest of the stack on the same key and the same bill, if EU operation and residency drive the decision, or if you want Postgres 18 today with the major pinned for the life of the database. Not if you need more than one region this quarter, and not if the branching mechanism is the deciding feature.

Try them against your own workload

The fastest way to settle any of this is to create a database on two of them and run your own migration and your own query pattern. Branch mechanics, restore behaviour and idle wake time are all things you can measure in an afternoon, and the measurement will beat anybody’s comparison table, including this one.

If you want to test the from-scratch engine, you can create a database on 16, 17 or 18 at Scalix Nova without a card, on a one time trial credit, and the rates are on the pricing page. If one of the others turns out to fit your workload better, that is a good outcome and we would rather you found out early. Come argue with any of the above on Discord.