Convex vs alternatives: reactive backend platforms compared Pricing Compared

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.