Convex vs Supabase

The honest framing is that these are not the same category of product wearing different logos. Supabase is Postgres with an excellent set of services bolted around it — auth, storage, edge functions, a realtime broadcast layer, a good dashboard. Convex is a purpose-built reactive database where queries are TypeScript functions and every query is a live subscription by default. One is infrastructure you rent; the other is a programming model you adopt.

That difference decides almost everything downstream. On Supabase, the thing you're writing is SQL and the thing you own is a Postgres database. On Convex, the thing you're writing is a query function and the thing you own is application code that only runs on Convex.

For a realtime, collaborative, or agent-driven app being built by a small TypeScript team, Convex is the faster path and the fewer-bugs path. You do not write cache invalidation, you do not write a websocket layer, you do not reconcile optimistic updates by hand, and you do not maintain a second copy of your schema in a validation library. The transactional guarantees are real ones — functions run in a serialisable transaction, and a query that reads three tables sees a consistent snapshot of all three.

For anything where the data is likely to outlive the application — analytics, reporting, an eventual data team, a product with an acquisition-shaped future — Supabase is the safer call. Postgres is the most portable thing in this comparison. Every BI tool speaks it, every ORM speaks it, every LLM writes it, and if Supabase ever prices itself out of your budget you move the database to Neon, RDS, Hetzner or your own box in an afternoon.

Our score weights portability heavily, which is why the two land closer than the marketing on either side would suggest. Ignore the composite if your situation is lopsided: exit cost matters enormously to a Series A company and almost nothing to a weekend project.

This is the single biggest technical difference and it is worth being precise about.

In Convex, a query is a TypeScript function that reads from the database. The runtime records exactly which documents that function touched, and when any of them change it re-runs the function and pushes the new result to every client subscribed to it. You never say "invalidate this". Your React component calls a hook, the hook holds a live value, and the value is correct. Consistency is per-query and transactional, so a query joining three tables cannot return a half-updated view.

Supabase's realtime is a different mechanism with a different contract. It streams Postgres logical replication changes over a websocket: you subscribe to a table, optionally with a filter, and receive INSERT/UPDATE/DELETE events. That is a powerful primitive, but it is row-level, not query-level. If your UI shows a derived value — a count, a join, an aggregate — you are responsible for translating "row 4192 changed" into "recompute this". Most teams end up pairing it with a client cache like TanStack Query and writing invalidation rules by hand.

For simple lists, both work fine. For a screen showing several derived values that must agree with each other, Convex removes work that Supabase makes you do. If your app has no live surfaces at all, this section doesn't matter and you should decide on the other axes.

Our killer field on the Convex alternatives hub is exit cost — a scored estimate of how much application code must be rewritten to leave. It exists because it is the actual question behind "should I use Convex", and no vendor will ever answer it.

Leaving Supabase is close to a data migration. Your tables are Postgres tables; pg_dump produces a file that restores anywhere. What you leave behind is the ancillary layer — auth users and their hashed credentials, storage buckets, RLS policies expressed in Supabase's idioms, and any Edge Functions. That is real work, typically days to a couple of weeks, but the core asset moves intact and your SQL keeps running.

Leaving Convex is a rewrite of the data layer. The documents export cleanly — that part is fine, and Convex does not hold your data hostage. But your queries and mutations are Convex functions using the Convex query builder, your reactivity is Convex subscriptions, and your scheduled jobs are Convex crons. None of that is portable. You are rewriting to Postgres plus an ORM plus a realtime story plus a job runner, and re-testing all of it.

The correct way to hold this: exit cost is a real liability, and it is also frequently the right trade. A team that ships six months earlier because it didn't build a realtime layer has bought itself the runway to afford a migration later. Just make the trade deliberately, and don't let anyone tell you it isn't a trade.

Supabase prices like infrastructure: a flat platform fee per project on paid plans, then compute sized by instance, plus storage and egress. It is predictable and it is easy to model on a spreadsheet. The surprises are that a paused free project needs restoring, that compute is the line item that actually grows, and that bandwidth on media-heavy apps adds up faster than teams expect.

Convex prices like a platform: function calls, action compute time, database bandwidth and storage. It is generous at the bottom and the free tier carries a real side project comfortably. The surprise is the reactive model's own cost shape — a query that fans out to many subscribers re-runs on every write to any document it read. A poorly scoped query over a hot table can multiply your function-call bill in a way that has no analogue in a request-per-page architecture. This is manageable (scope queries narrowly, paginate, avoid reading giant collections in a subscribed query) but it is a discipline you have to learn.

Neither is expensive at small scale. Both are cheaper than a two-week detour building the thing they give you. Model your own numbers on the pricing fields in the category table rather than trusting either landing page.

Supabase's auth is the more complete product: email and password, magic links, a long list of OAuth providers, phone OTP, MFA, and — critically — it issues a JWT that Postgres itself reads for row-level security. That integration is genuinely elegant. The cost is that RLS is easy to get subtly wrong, and getting it wrong means a data leak rather than a broken page. Test policies deliberately.

Convex leans on external identity providers, with first-class integrations for Clerk and Auth0 and its own auth library for teams that want fewer vendors. Authorisation lives in your query and mutation functions as ordinary TypeScript. Most developers find that easier to reason about and easier to test than policy DSLs, at the cost of it being your job to remember the check in every function.

Both include file storage with signed URLs, both include vector search suitable for retrieval, both have full-text search that is fine for in-app search and not a Meilisearch or Typesense replacement. Supabase's dashboard is the better data-browsing experience; Convex's dashboard is the better function-observability experience, with live logs and function-level history that make debugging obvious.

If you want a third option, the same hub covers InstantDB, Triplit and ElectricSQL for local-first, and PocketBase and Appwrite for self-hosted single-binary deployments.