Neon, Supabase, PlanetScale, Turso: Picking a Database for Next.js

The four names in the title are not four brands of the same thing. Under each one is a different decision about where the data lives and what sits in front of it, and those decisions reach your code.

Here is what each is actually selling, and where it shows through.

Neon: Postgres with storage split from compute

The distinctive feature is not serverless pricing. It is that the storage layer is separate from the compute, which makes a database branch a copy-on-write operation rather than a dump and restore.

What that buys. A branch per pull request, at production data scale, in seconds. Migrations tested against real row counts in CI rather than against a seeded table. For a team that has ever had a migration behave differently in production, this is the feature worth paying for.

What to watch. Compute suspends when idle, which is a saving if your traffic genuinely has quiet periods and a cold start if it does not. And anything polling the database on a timer will keep it awake, so the saving is easy to lose without noticing.

The HTTP driver is the other reason it comes up in Next.js conversations - it removes connection pooling as a problem for simple read paths, with the caveats that come with one-shot queries.

Supabase: Postgres plus the things around it

Supabase is a real Postgres with auth, object storage, realtime subscriptions and an auto-generated API on top. The comparison is only partly about the database.

What that buys. If you need authentication and file storage anyway, having them share an identity model with your data is a genuine saving - and row-level security means an authorisation rule can live in the database rather than being re-implemented in every route that touches the table.

What to watch. RLS is powerful and it is a second place authorisation lives. A policy that is subtly wrong fails open, and it is not visible in your application code. Whatever you adopt, adopt deliberately: either the database owns access control or the application does, and having both is how the two disagree.

If you use it only as a Postgres host, compare it as one. Most of its value is in the parts you would otherwise build.

PlanetScale: MySQL, sharded underneath

Vitess under the hood, which is the technology that let large MySQL deployments scale horizontally. The developer-facing feature is a schema workflow: branches and deploy requests, with schema changes applied without locking.

What that buys. Non-blocking schema changes on very large tables, which is a real and difficult problem solved properly. And a review workflow for schema that looks like the one you already use for code.

What to watch. The sharding model is why foreign key support has been a moving target - cross-shard referential integrity is genuinely expensive, and what is supported has changed over time. Check the current behaviour before you rely on it. A foreign key that is accepted and not enforced is worse than one that is refused, because your application believes something the database is not doing.

It is also MySQL, so if your schema wants jsonb, partial indexes or extensions, it is the wrong list.

Turso: SQLite, distributed

SQLite as a service, replicated to locations near your users, spoken to over HTTP.

What that buys. Very low read latency from anywhere, because the read is local rather than crossing an ocean. And the operational simplicity of SQLite with the durability story you would otherwise have to build.

What to watch. Writes go to a primary, so a write is not local and the latency profile is asymmetric. And it is SQLite - loose typing, a different function set, and a concurrency model built around one writer. For read-dominated data with a small write path it is excellent. For a transactional application with contended writes it is the wrong shape.

How to choose without a spreadsheet

Answer three questions and the list narrows itself.

Does your schema want Postgres features? JSON you will query, partial indexes, check constraints, extensions, PostGIS. If yes, two of the four are out immediately, and that is most of the decision made.

Is your traffic spiky or steady? Genuinely spiky - a campaign, a seasonal product, a B2B tool nobody touches at weekends - is what consumption pricing is for. Steady traffic on a fixed instance is almost always cheaper and is the unfashionable correct answer for a lot of applications.

Are you buying a database or a backend? If auth, storage and realtime are on your list anyway, a platform that includes them is a different and better deal than a database plus three services. If they are not, you are comparing Postgres hosts.

The part that is not the database

Whichever you choose, the Next.js-specific work is the same: one client per module scope, the pooled endpoint for requests and the direct one for migrations, and a decision about where queries live. Those cost an afternoon and they determine whether the platform behaves.

Choosing the perfect provider and constructing a client inside a route handler gets you a connection-limit error on a very well-engineered database.