Convex vs the alternatives

Convex genuinely wins the thing it claims to win. One TypeScript project holds the schema, the server functions and the client types; queries are reactive by default with no subscription plumbing; mutations are transactional with no connection pool to think about. Nothing else on this list gets a competent developer to a working realtime feature faster, and it is the roster's best fit for a coding agent because the whole surface is typed and in-repo. Its transaction model — optimistic concurrency with automatic retries — is also the only one here that makes serialisable writes the boring default rather than something you opt into.

The cost is not the price and it is not the limits. It is that every read and write in your application is expressed in Convex's query builder, executed by Convex's runtime, and delivered by Convex's reactivity. There is no SQL to port. Leaving is a rewrite of the data layer plus the render model that hangs off it, and open-sourcing the backend does not change that. Convex self-hosting is real and it does bound the vendor risk, but self-hosting Convex is still Convex. Score the exit honestly before you start, not after.

If you want most of the productivity for a fraction of the exit cost, Supabase is the pragmatic answer and has been for three years. Your data is Postgres, your queries are SQL or PostgREST over SQL, and pg_dump is a complete escape hatch. What you give up is coherence: auth, storage, realtime and edge functions are four products stitched together, realtime is a change feed you subscribe to rather than a reactive query, and types come from a CLI step rather than inference. Nhost is the same trade with Hasura's GraphQL in place of PostgREST — smaller, quieter, and worth a look if GraphQL is already in your stack.

The interesting movement is at the sync layer. ElectricSQL and Zero both refuse to own your database. Electric streams read shapes out of your Postgres over HTTP and leaves writes to your existing API; Zero puts a query-shaped client cache in front of Postgres with server-side mutators. That inverts the lock-in question — you adopt a sync engine, not a backend — which is why they score 2 and 3 on exit cost while delivering local-first behaviour Convex does not have at all. They are also younger, thinner on batteries (no storage, no auth, no cron), and will make you build the parts Convex hands you.

Firebase is the cautionary tale at the other end. It is the only entry here with no self-host path, a proprietary security-rules language, an export format only Firestore can read, and a document model that quietly shapes your schema around its query limitations. It still has the deepest mobile SDKs and Google's operational record, and for a consumer mobile app that will never migrate, that is a defensible choice. For anything you expect to still be running and still be changing in five years, it is the worst deal on this page.

Every vendor on this page will tell you your data is yours. That is true, and it is not the question. Data extraction is a weekend for nine of these eleven; rewriting the two thousand call sites that read that data is not.

The ladder is about code, not bytes. Rung 1 is standard SQL over the wire — leaving is a connection string. Rung 2 is a standard engine behind a vendor SDK: your schema and your queries port intact, but the auth, storage and realtime call sites get rewritten. Rung 3 is a proprietary API over an open engine you can self-host, so the data leaves cleanly but every read and write is vendor-shaped. Rung 4 adds a proprietary function runtime on top, so queries, mutations, subscriptions and the reactive render model all go. Rung 5 is rung 4 with no self-host and no self-serve bulk export, which makes even the data a project.

Two things fall out of this. First, open source does not lower the score by itself — Appwrite, PocketBase and Convex are all open source and all sit at 3 or 4, because the licence governs who may run the server, not who has to rewrite the client. Second, the sync engines score unusually well for how new they are, because they sit beside a Postgres you already control rather than replacing it.

The sticker prices here cluster between $15 and $30 a month and tell you almost nothing. Three mechanics decide the real bill.

Per-seat pricing. Convex and Appwrite charge per member on top of usage, so a five-person team starts at five times the headline before a single function runs. Supabase charges per organisation; Firebase charges nothing up front. On a small team this is usually the largest single line, and it is the one that does not shrink when you optimise.

Bandwidth. Convex, Supabase, Firebase, Appwrite and Nhost all meter egress separately from storage and compute. Reactive backends push data on every change, so a chatty subscription is a bandwidth line item rather than a CPU one — easy to miss when you model costs against requests per second. Check what your live queries actually re-send when one row changes.

Idle. Firebase, Convex and Neon cost approximately nothing when nobody is using them. A Supabase Pro project bills compute by the hour whether or not it serves traffic, and anything self-hosted bills you for the machine. For side projects and staging environments this dominates everything else on the page.

Convex to Postgres is the hard one, and worth planning before you need it. npx convex export gives you a zip of JSONL per table, which loads into Postgres cleanly enough; the work is in the application. The pattern that survives contact with reality is to put a repository layer between your components and Convex early, so the reactive queries become one seam instead of several hundred. Do it while the app is small — retrofitting it later is most of the cost of the migration itself.

Firebase to anything starts with the export format, the one genuinely closed artefact on this page: the managed Firestore export writes a format only Firestore imports. In practice you paginate collections through the Admin SDK and write your own JSON, which is fine at gigabytes and painful at terabytes. Budget separately for translating security rules into row-level security or middleware, because there is no mechanical translation.

Supabase to plain Postgres is the easy case and worth naming as the reference point: pg_dump, restore anywhere, replace supabase-js calls with your query builder, replace GoTrue with an auth provider. Weeks, not quarters. That gap — weeks against quarters — is the entire content of the exit-cost column.

Adding a sync engine later is the underrated option. Because Electric and Zero sit beside Postgres rather than replacing it, "start on Neon and Drizzle, add Zero when the UI needs to feel instant" is a real sequence rather than a rewrite. None of the all-in-one platforms support that shape.

Every cell was written from vendor documentation, public pricing pages and hands-on knowledge of the SDKs, then tagged with its provenance. Cells marked vendor-claimed come off a specific docs or pricing URL and carry the date the claim was last plausibly true. Cells marked inferred are judgement calls or values reasoned from adjacent facts. Where a fact is genuinely not published — Triplit's hosted pricing, several function timeouts, every star count to better than a thousand — the cell is null and renders as an em dash rather than a confident guess. Prices are the lowest paid tier, monthly, in USD, excluding usage.

Exit cost is the field this page exists for. It is a 1–5 judgement score, lower is better, and it measures one thing: how much application code you rewrite to move off the platform, assuming the data is already extracted. It deliberately ignores how good the platform is, how cheap it is, and how likely the vendor is to survive. A high score is not a verdict against a tool — it is the size of the bet you are placing. The five rungs are defined in the column tooltip, every score is a judgement rather than a measurement, and the reasoning for each sits in that tool's cell note.