Neon vs Supabase vs Turso vs Convex: which database?

The database question for a new app used to be "Postgres or Mongo". Now it is Postgres or SQLite, serverless or always-on, a database or a backend, and each of the popular choices answers it differently. This is a comparison of the four that come up most, on the dimensions that end up deciding it. None of them is the wrong choice; they are choices for different apps.

The short version

• Neon: serverless Postgres with branching. Pick it when you want plain Postgres, a bill that goes to zero when nobody is using the app, and a database copy per pull request.
• Supabase: Postgres plus auth, storage, realtime and functions. Pick it when you want the backend as well as the database, and you want it all to be Postgres underneath.
• Turso: SQLite-compatible, replicated to where your code runs. Pick it when latency matters more than write throughput, or when you want one database per user or tenant.
• Convex: a reactive backend where queries are TypeScript functions and the UI updates when data changes. Pick it when the app is collaborative or live, and you would rather not write the sync layer yourself.

Query model

Neon and Supabase are Postgres. SQL, every extension that Postgres users expect, every ORM, every tool. If you already think in SQL, both feel like nothing new, which is the point. Prisma or Drizzle sit on top of either without complaint.

Turso is SQLite's dialect through libSQL, with the same ORMs supporting it. SQLite's model is simpler than Postgres', which is fine for most apps and a surprise for the ones that lean on advanced types, full-text search configurations or stored procedures.

Convex is not SQL. Queries and mutations are TypeScript functions running inside Convex, with a document model and indexes you declare in code. The functions are reactive: a component subscribed to a query re-renders when the underlying data changes, with no polling and no websockets written by you. It is the most productive of the four for a live app and the biggest departure from what you know.

Where it runs and what it costs at zero

Neon separates storage from compute, so compute scales to zero when idle and wakes on the first query. Cold starts are short but real; the free tier is generous for side projects, and branching lets each preview deployment get its own copy of the database that costs almost nothing while idle.

Supabase runs a dedicated Postgres instance per project. It does not scale to zero, which means no cold starts and a fixed cost per project once you are past the free tier. The free tier pauses inactive projects, which trips people up on hobby apps.

Turso's trick is replicas. The primary lives in one region; replicas can live near your users or embedded next to your application code, so reads are local and effectively free in latency terms. Writes go to the primary. The pricing is per database and per row read, which makes the many-small-databases pattern cheap.

Convex is hosted and priced on function calls, storage and bandwidth. There is an open source backend you can self-host, but the product is the hosted version, and the pricing rewards apps with lots of readers and modest write volume.

Realtime and collaboration

Convex wins this outright because it is the premise of the product. Supabase has realtime subscriptions on Postgres changes, which cover "update the list when a row changes" well and get harder when you want conflict resolution. Neon and Turso are databases; you bring your own realtime layer, and both pair well with a service built for it.

Auth, storage and the rest

Supabase ships them: auth with social providers and row level security, file storage, edge functions, a vector extension. For a solo founder that is a week of work you do not do.

Neon is only the database, by design, and pairs with whatever auth you chose. Turso likewise. Convex has auth integrations and file storage, and its functions replace what you would otherwise write as an API layer.

How hard it is to leave

Neon: pg_dump, done. It is Postgres.

Supabase: also Postgres, so the data leaves easily. The auth, storage and realtime layers are the lock-in, and they are open source, so you can run them yourself if it comes to that.

Turso: SQLite files. You can literally download the database. The replication layer is the product; the data is not captive.

Convex: the data exports, but the functions, the reactivity and the schema are Convex's model. Leaving means rewriting the data layer, which is the price of not having written it in the first place.

A reasonable default

For a typical SaaS with a web frontend, start on Neon or Supabase and decide based on whether you want the backend bundle. Reach for Turso when you know latency or per-tenant isolation is the problem. Reach for Convex when the app is live by nature and you want the sync layer to be someone else's problem.

Upstash deserves a mention as the thing you add to any of these: serverless Redis for caching, rate limits and queues, priced per request, which is the piece every one of the four leaves out.

The databases category on TeaserTrack lists these alongside the newer entrants, and the data infrastructure collection is the most upvoted of them in one place. The next database worth knowing about tends to appear there as a beta a year before it appears in a comparison like this one.