---
title: "Convex vs alternatives: reactive backend platforms compared"
slug: convex-alternatives
url: "https://toolweight.dev/compare/convex-alternatives"
question: What are the best alternatives to Convex, and how hard is each one to leave?
tools: 11
fields: 26
last_verified: 2026-07-20
freshness: 42%
verify_cadence: 30d
license: CC-BY-4.0
---

# Convex vs the alternatives

> **What are the best alternatives to Convex, and how hard is each one to leave?**
>
> Convex is the fastest of these to ship on and among the hardest to leave: the query API and function runtime are proprietary, so exiting means rewriting every call site. Supabase, Nhost and plain Neon keep your data and your queries in ordinary Postgres. Zero and ElectricSQL add sync on top of a Postgres you already own.

## At a glance

|  |  |
| --- | --- |
| Canonical | https://toolweight.dev/compare/convex-alternatives |
| Tools compared | 11 |
| Fields compared | 26 |
| Last verified | 2026-07-20 (3d ago) |
| Verify cadence | 30d |
| Freshness | 42% (mean cell confidence) |
| Killer field | exit_cost |
| Scoring | Weighted, re-rankable |
| Licence | CC-BY-4.0 — https://creativecommons.org/licenses/by/4.0/ |

## Ranking — default weights

| # | Tool | Score | Coverage | One-liner |
| --- | --- | --- | --- | --- |
| 1 | [Supabase](https://toolweight.dev/tools/supabase) | 74.6 | 100% | Managed Postgres with auth, storage, realtime and edge functions around it. |
| 2 | [Nhost](https://toolweight.dev/tools/nhost) | 72.0 | 91% | Postgres plus Hasura GraphQL, auth, storage and serverless functions. |
| 3 | [Zero](https://toolweight.dev/tools/rocicorp-zero) | 70.9 | 91% | Sync engine that puts a queryable client cache in front of your own Postgres. |
| 4 | [PocketBase](https://toolweight.dev/tools/pocketbase) | 66.6 | 96% | One Go binary: SQLite database, auth, file storage, realtime and an admin UI. |
| 5 | [Convex](https://toolweight.dev/tools/convex) | 65.5 | 100% | Reactive TypeScript backend: database, functions and live queries in one project. |
| 6 | [ElectricSQL](https://toolweight.dev/tools/electricsql) | 62.0 | 87% | Postgres read-path sync: stream subsets of your own database to clients over HTTP. |
| 7 | [Neon + Drizzle](https://toolweight.dev/tools/neon-drizzle) | 60.5 | 96% | The DIY baseline: serverless Postgres, a typed SQL query builder, nothing else. |
| 8 | [InstantDB](https://toolweight.dev/tools/instantdb) | 57.8 | 87% | Client-side reactive database with a relational graph model and instant sync. |
| 9 | [Appwrite](https://toolweight.dev/tools/appwrite) | 54.6 | 100% | Open-source backend platform: databases, auth, storage, functions, self-hostable. |
| 10 | [Firebase](https://toolweight.dev/tools/firebase) | 51.2 | 96% | Google's app platform: Firestore documents, auth, functions, deep mobile SDKs. |
| 11 | [Triplit](https://toolweight.dev/tools/triplit) | 50.4 | 83% | Full-stack database that syncs: local cache, server, relational queries, offline. |

Re-rank against your own priorities by appending `?w=field_id:weight,…` to the canonical URL, or call `score_tools` on the MCP server at `https://toolweight.dev/mcp`.

## Comparison

### Features

| Tool | Reactivity | TS inference | Transactions | Local-first sync | Optimistic writes | Cron & scheduling | File storage | Vector search | Full-text search | Auth | Hard limits | Cold start (ms) | Function timeout (ms) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Supabase | push | ◐ | mvcc | ○ | ○ | ● | ● | ● | ● | built-in | Postgres limits apply: about 1 GB per field, no vendor row cap. The real ceilings are connection count and the compute tier you pay for. | 250 ms | 2.5 min |
| Nhost | push | ◐ | mvcc | ○ | ○ | ● | ● | ● | ● | built-in | Postgres limits, plus Hasura's own query-depth and rate limiting on the managed tiers. | — | — |
| Zero | push | ● | mvcc | ● | ● | ○ | ○ | ◐ | ◐ | bring-your-own | Client cache size is the practical ceiling — the query set you sync has to fit on the device. | — | — |
| PocketBase | push | ◐ | serialisable | ○ | ○ | ◐ | ● | ○ | ◐ | built-in | One machine. SQLite tops out near a billion bytes per value and a single concurrent writer; everything else is your disk and RAM. | 0 ms | — |
| Convex | push | ● | occ | ○ | ● | ● | ● | ● | ● | first-party-addon | 1 MiB per document; roughly 16k documents or 8 MiB scanned per query; queries and mutations capped near 1s of compute. | 0 ms | 10 min |
| ElectricSQL | push | ◐ | mvcc | ◐ | ◐ | ○ | ○ | ◐ | ◐ | bring-your-own | Shape size — a shape has to be small enough to hold on the client and cheap enough to re-materialise on the server. | — | — |
| Neon + Drizzle | manual | ● | mvcc | ○ | ○ | ○ | ○ | ● | ● | bring-your-own | Postgres limits. The operational ceiling is your compute size and connection count, both dials you control. | 500 ms | — |
| InstantDB | push | ● | occ | ● | ● | ○ | ● | ○ | ○ | built-in | — | — | — |
| Appwrite | push | ◐ | none | ○ | ○ | ● | ● | ○ | ◐ | built-in | Attribute count per collection is bounded by the underlying MariaDB row width — wide documents fail at creation time rather than at scale. | 1 s | 15 min |
| Firebase | push | ○ | occ | ◐ | ● | ● | ● | ● | ○ | built-in | 1 MiB per document; about one sustained write per second per document; 500 operations per transaction; no joins. | 2 s | 60 min |
| Triplit | push | ● | occ | ● | ● | ○ | ○ | ○ | ○ | bring-your-own | — | — | — |

### Portability & exit

| Tool | Exit cost | Self-hostable | Bulk export | Raw SQL | Schema changes |
| --- | --- | --- | --- | --- | --- |
| Supabase | 2 | ● | ● | ● | sql-migrations |
| Nhost | 2 | ● | ● | ● | sql-migrations |
| Zero | 3 | ● | ● | ● | sql-migrations |
| PocketBase | 3 | ● | ● | ● | declarative-push |
| Convex | 4 | ● | ● | ○ | declarative-push |
| ElectricSQL | 2 | ● | ● | ● | sql-migrations |
| Neon + Drizzle | 1 | ◐ | ● | ● | sql-migrations |
| InstantDB | 4 | ◐ | ◐ | ○ | declarative-push |
| Appwrite | 3 | ● | ◐ | ○ | declarative-push |
| Firebase | 5 | ○ | ◐ | ○ | schemaless |
| Triplit | 4 | ● | ◐ | ○ | declarative-push |

### Agentic

| Tool | MCP server | Agent fit |
| --- | --- | --- |
| Supabase | ● | 4 |
| Nhost | ● | 3 |
| Zero | ○ | 3 |
| PocketBase | ○ | 3 |
| Convex | ● | 5 |
| ElectricSQL | ○ | 2 |
| Neon + Drizzle | ● | 4 |
| InstantDB | ● | 4 |
| Appwrite | ● | 3 |
| Firebase | ● | 2 |
| Triplit | ○ | 3 |

### Pricing

| Tool | Pricing model | Entry price (/mo) | Egress metered |
| --- | --- | --- | --- |
| Supabase | flat per org + compute + usage | $25 /mo | ● |
| Nhost | flat per project + usage | $25 /mo | ● |
| Zero | free (self-host) | $0 /mo | ○ |
| PocketBase | free (self-host only) | $0 /mo | ○ |
| Convex | per-seat + usage | $25 /mo | ● |
| ElectricSQL | free (self-host) + optional cloud | — | ◐ |
| Neon + Drizzle | flat + compute-hours + storage | $19 /mo | ◐ |
| InstantDB | flat + usage | $30 /mo | — |
| Appwrite | per-seat + usage | $15 /mo | ● |
| Firebase | usage only (Blaze pay-as-you-go) | $0 /mo | ● |
| Triplit | — | — | — |

### Traction

| Tool | GitHub stars | Backing |
| --- | --- | --- |
| Supabase | 90,000 | venture-backed |
| Nhost | 8,000 | venture-backed |
| Zero | 3,000 | venture-backed |
| PocketBase | 48,000 | solo-maintainer |
| Convex | 8,000 | venture-backed |
| ElectricSQL | 8,000 | venture-backed |
| Neon + Drizzle | 18,000 | big-tech |
| InstantDB | 9,000 | venture-backed |
| Appwrite | 52,000 | venture-backed |
| Firebase | — | big-tech |
| Triplit | 4,000 | venture-backed |

### Positioning

| Tool | Positioning |
| --- | --- |
| Supabase | The Postgres development platform — the open-source Firebase alternative. |
| Nhost | The open-source Firebase alternative, with GraphQL. |
| Zero | A general-purpose sync engine for the web. |
| PocketBase | Open-source backend in one file. |
| Convex | The open-source reactive database for app developers. |
| ElectricSQL | Postgres sync engine — sync little subsets of your data into local apps. |
| Neon + Drizzle | Serverless Postgres with branching, paired with a typed SQL query builder. |
| InstantDB | A modern Firebase — a client-side database that syncs. |
| Appwrite | Build like a team of hundreds — an open-source backend platform. |
| Firebase | Google's platform for building and running app backends. |
| Triplit | The full-stack database that syncs. |

## Field registry

| Field | id | Group | Type | Unit | Better | Default weight | Definition |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Reactivity | `reactivity_model` | features | enum | — | higher | 7 | How a client learns that a query result changed. push = the server invalidates and re-delivers results without the client asking; poll = the client re-fetches on an interval or on focus; manual = nothing happens until your code refetches. |
| TS inference | `ts_inference` | features | tristate | — | higher | 6 | Whether a schema change flows to client-side types with no separate codegen step. yes = types inferred from the schema at compile time; partial = a CLI generates types you commit or regenerate; no = types are hand-written or absent. |
| Transactions | `transaction_semantics` | features | enum | — | higher | 5 | The concurrency control the primary store exposes to application code. mvcc = Postgres-style multi-version snapshots; serialisable = single-writer serialised commits; occ = optimistic concurrency with conflict detection and retry; batch-atomic = all-or-nothing writes over a bounded set with no general isolation; none = no multi-record atomicity. |
| Local-first sync | `local_first_sync` | features | tristate | — | higher | 5 | Whether the client keeps a queryable local store that serves reads offline and reconciles with the server on reconnect. yes = full local query engine plus write reconciliation; partial = offline cache and write queue, or read-path sync only; no = every read needs the network. |
| Optimistic writes | `optimistic_updates` | features | tristate | — | higher | 4 | Whether the platform applies a pending write to local query results and rolls it back on failure, as a first-party API rather than something you assemble over a cache library. |
| Cron & scheduling | `scheduled_functions` | features | tristate | — | higher | 4 | First-party cron and delayed-job scheduling that runs on the platform. yes = declarative crons plus one-off scheduling from application code; partial = one of the two, or a scheduler bolted on from elsewhere; no = bring your own worker. |
| File storage | `file_storage` | features | tristate | — | higher | 3 | Blob storage included in the platform, with access control tied to the same auth and addressable from the same SDK. |
| Vector search | `vector_search` | features | tristate | — | higher | 2 | First-party vector indexing and nearest-neighbour queries over stored records. partial = available through the underlying database but not a product feature the platform manages. |
| Full-text search | `full_text_search` | features | tristate | — | higher | 3 | First-party text indexing with relevance ranking. partial = substring or LIKE filtering only, or an index without ranking; no = you attach an external search service. |
| Auth | `auth_included` | features | enum | — | higher | 4 | Where user identity lives. built-in = the platform stores users and sessions and the database enforces rules against them; first-party-addon = an official library you install and wire up; bring-your-own = the platform verifies a JWT you issue elsewhere. |
| Hard limits | `hard_limits` | features | text | — | n/a | 0 | The documented per-record and per-query ceilings a real application hits first. Not scored — it is here so you can check your data model against them before committing. |
| Cold start | `cold_start` | features | duration | ms | lower | 3 | Added latency on the first request after an idle period, for the platform's own function runtime or compute. 0 means there is no user-visible cold path; null means there is no function runtime to cold-start. |
| Function timeout | `function_timeout` | features | duration | ms | higher | 2 | Maximum wall-clock runtime for the longest-running server function the platform will execute, on the lowest paid tier. Read the note — several platforms cap database-touching functions far lower than this headline. |
| Exit cost | `exit_cost` | portability | score | — | lower | 10 | 1–5 judgement score, lower is better, for how much application code must be rewritten to move off the platform, assuming the data is already extracted. 1 = standard SQL over the wire; leaving is a connection string. 2 = standard engine behind a vendor SDK; schema and queries port, but auth, storage and realtime call sites are rewritten. 3 = proprietary API over an open, self-hostable engine; data leaves cleanly but every read and write call site is vendor-shaped. 4 = proprietary query language plus a proprietary function runtime; queries, mutations, subscriptions and the reactive render model are all rewritten. 5 = as 4, plus no self-host and no self-serve bulk export, so extracting the data is itself a project. |
| Self-hostable | `self_hostable` | portability | tristate | — | higher | 6 | Whether you can run the server yourself on your own infrastructure with a documented path. partial = possible but materially harder than the hosted product, or missing features the cloud version has. |
| Bulk export | `bulk_export` | portability | tristate | — | higher | 5 | Whether you can pull every record out in an open format, self-serve, without a support ticket. partial = per-collection API pagination you script yourself, or an export format only the vendor's own importer reads. |
| Raw SQL | `raw_sql` | portability | tristate | — | higher | 5 | Whether you can execute arbitrary SQL against the primary store — the thing that decides whether BI tools, analytics jobs, ad-hoc backfills and third-party ORMs can reach your data at all. |
| Schema changes | `schema_migrations` | portability | enum | — | higher | 4 | How a schema change is expressed and applied. sql-migrations = versioned, reviewable migration files run in order; declarative-push = you edit a schema definition and the platform diffs and applies it, with data backfills written by hand; schemaless = no enforced schema, shape changes handled in application code; none = no schema concept. |
| MCP server | `mcp_server` | agentic | tristate | — | higher | 4 | An official Model Context Protocol server, published by the vendor, that lets a coding agent inspect the schema and operate on a project. partial = community-maintained only. |
| Agent fit | `agent_fit` | agentic | score | — | higher | 4 | 1–5 judgement score for how far a coding agent can take a feature end-to-end without human plumbing. Rewards schema, server logic and client types living in one typed repository, a local dev loop the agent can run, and errors that name the fix. Penalises console-only configuration, out-of-band dashboards and untyped string DSLs. |
| Pricing model | `pricing_model` | pricing | price-model | — | n/a | 0 | The shape of the bill, which matters more than the headline number. Not scored — read it alongside entry price and metered egress. |
| Entry price | `entry_price` | pricing | currency | /mo | lower | 5 | Monthly cost of the cheapest paid tier, excluding usage, in USD. 0 means the software is free and you pay only for the machine it runs on. Per-seat plans are shown at one seat — multiply by your team size. |
| Egress metered | `egress_billing` | pricing | tristate | — | lower | 3 | Whether bandwidth out is metered and billed as a separate line beyond an included allowance. yes is worse. It bites reactive backends hardest, because a chatty subscription re-sends data on every change. |
| GitHub stars | `github_stars` | traction | number | — | higher | 2 | Stars on the primary open-source repository, rounded to the nearest thousand. A popularity proxy, not a quality signal, and meaningless for closed products. |
| Backing | `backing` | traction | enum | — | higher | 2 | Who pays for development. A crude survival proxy only: big-tech products get deprecated and solo-maintained projects outlive funding rounds. Weight it low unless you are betting a decade on the choice. |
| Positioning | `positioning` | marketing | text | — | n/a | 0 | How the vendor describes itself, paraphrased from its own homepage. Useful mainly for spotting the gap between the pitch and the table above. |

## Presets

| Preset | id | What it optimises for | Weights | Ranked URL |
| --- | --- | --- | --- | --- |
| Fastest to ship | `fastest-to-ship` | End-to-end types, push reactivity, batteries included and agent legibility. Ignores exit cost almost entirely. | ts_inference:9, reactivity_model:8, auth_included:7, optimistic_updates:6, file_storage:6, agent_fit:6, scheduled_functions:5, mcp_server:4, schema_migrations:4, full_text_search:3, vector_search:3, exit_cost:1 | https://toolweight.dev/compare/convex-alternatives?w=ts_inference:9,reactivity_model:8,auth_included:7,optimistic_updates:6,file_storage:6,agent_fit:6,scheduled_functions:5,mcp_server:4,schema_migrations:4,full_text_search:3,vector_search:3,exit_cost:1 |
| Most portable | `most-portable` | Exit cost dominates, backed by raw SQL access, self-hosting and a self-serve bulk export. | exit_cost:10, raw_sql:9, bulk_export:8, self_hostable:8, schema_migrations:5, transaction_semantics:4, backing:3, ts_inference:2 | https://toolweight.dev/compare/convex-alternatives?w=exit_cost:10,raw_sql:9,bulk_export:8,self_hostable:8,schema_migrations:5,transaction_semantics:4,backing:3,ts_inference:2 |
| Best local-first | `best-local-first` | For apps that must work offline and feel instant: local sync, built-in optimistic writes, push reactivity. | local_first_sync:10, optimistic_updates:8, reactivity_model:7, ts_inference:5, transaction_semantics:4, exit_cost:3, github_stars:2 | https://toolweight.dev/compare/convex-alternatives?w=local_first_sync:10,optimistic_updates:8,reactivity_model:7,ts_inference:5,transaction_semantics:4,exit_cost:3,github_stars:2 |
| Cheapest at scale | `cheapest-at-scale` | Entry price, metered egress and the option to run it yourself on a box you already pay for. | entry_price:8, egress_billing:8, self_hostable:7, raw_sql:4, cold_start:3, exit_cost:2 | https://toolweight.dev/compare/convex-alternatives?w=entry_price:8,egress_billing:8,self_hostable:7,raw_sql:4,cold_start:3,exit_cost:2 |

## Verdict

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.

## What exit cost actually measures

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.

## Where the pricing hides

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.

## Realistic migration paths

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.

## Provenance — every cell, every source

### Supabase {#supabase}

Managed Postgres with auth, storage, realtime and edge functions around it.

|  |  |
| --- | --- |
| Site | https://supabase.com |
| Docs | https://supabase.com/docs |
| Repo | https://github.com/supabase/supabase |
| Company | Supabase |
| Founded | 2020 |
| Funding | Venture-backed |
| Open source | Yes (Apache-2.0) |
| Profile | https://toolweight.dev/tools/supabase |
| Score (default weights) | 74.6 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/realtime | A Postgres change feed pushed over websockets — you subscribe to table changes, not to query results, so re-deriving state is your job. | #supabase-reactivity_model |
| TS inference | ◐ | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/api/rest/generating-types | CLI codegen from the live schema; you re-run it and commit the file. | #supabase-ts_inference |
| Transactions | mvcc | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/database | Plain Postgres, but PostgREST calls are one statement each — multi-step transactions need an RPC. | #supabase-transaction_semantics |
| Local-first sync | ○ | Inferred | — | — | — | #supabase-local_first_sync |
| Optimistic writes | ○ | Inferred | — | — | No first-party API; teams use TanStack Query or similar. | #supabase-optimistic_updates |
| Cron & scheduling | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/cron | pg_cron plus scheduled edge functions. | #supabase-scheduled_functions |
| File storage | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/storage | — | #supabase-file_storage |
| Vector search | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/ai | pgvector, managed. | #supabase-vector_search |
| Full-text search | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/database/full-text-search | — | #supabase-full_text_search |
| Auth | built-in | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/auth | — | #supabase-auth_included |
| Hard limits | Postgres limits apply: about 1 GB per field, no vendor row cap. The real ceilings are connection count and the compute tier you pay for. | Inferred | — | — | — | #supabase-hard_limits |
| Cold start | 250 ms | Community-reported | — | — | Deno edge function isolate start. Separately, free-tier projects pause after a week idle and take about a minute to restore. | #supabase-cold_start |
| Function timeout | 2.5 min | Inferred | — | — | Edge function wall clock; CPU time is capped far lower, on the order of a couple of seconds. | #supabase-function_timeout |
| Exit cost | 2 | Inferred | — | — | pg_dump takes the data and schema intact and SQL ports unchanged. You rewrite supabase-js call sites, swap GoTrue for another auth provider, and reimplement storage and realtime. Weeks, not quarters. | #supabase-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/self-hosting | Docker Compose stack; feature parity with Cloud lags. | #supabase-self_hostable |
| Bulk export | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/database/connecting-to-postgres | Direct Postgres connection; pg_dump works. | #supabase-bulk_export |
| Raw SQL | ● | Inferred | — | — | — | #supabase-raw_sql |
| Schema changes | sql-migrations | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/deployment/database-migrations | — | #supabase-schema_migrations |
| MCP server | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/docs/guides/getting-started/mcp | — | #supabase-mcp_server |
| Agent fit | 4 | Inferred | — | — | Strong CLI and local stack, but RLS policies and dashboard configuration sit outside the typed repo. | #supabase-agent_fit |
| Pricing model | flat per org + compute + usage | Vendor-claimed | 2026-07-20 | https://supabase.com/pricing | — | #supabase-pricing_model |
| Entry price | $25 /mo | Vendor-claimed | 2026-07-20 | https://supabase.com/pricing | Per organisation, not per seat. Compute for each project is billed on top and does not scale to zero. | #supabase-entry_price |
| Egress metered | ● | Vendor-claimed | 2026-07-20 | https://supabase.com/pricing | — | #supabase-egress_billing |
| GitHub stars | 90,000 | Inferred | — | — | Approximate as of mid-2026. | #supabase-github_stars |
| Backing | venture-backed | Inferred | — | — | — | #supabase-backing |
| Positioning | The Postgres development platform — the open-source Firebase alternative. | Vendor-claimed | 2026-07-20 | https://supabase.com | — | #supabase-positioning |

**Verdict.** The default choice for anyone who wants managed convenience without giving up their database. The seams show — four services, RLS in SQL, codegen instead of inference — but pg_dump is a complete exit, and that buys a lot of friction.

**Pick it when**

- Teams that need raw SQL, BI tooling or a third-party ORM against the same data
- Anyone who wants a credible migration path off the platform from day one
- Projects already comfortable with Postgres row-level security

### Nhost {#nhost}

Postgres plus Hasura GraphQL, auth, storage and serverless functions.

|  |  |
| --- | --- |
| Site | https://nhost.io |
| Docs | https://docs.nhost.io |
| Repo | https://github.com/nhost/nhost |
| Company | Nhost |
| Founded | 2020 |
| Funding | Venture-backed |
| Open source | Yes |
| Profile | https://toolweight.dev/tools/nhost |
| Score (default weights) | 72.0 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://docs.nhost.io/products/database | Hasura GraphQL subscriptions — a server-side diff pushed to clients. | #nhost-reactivity_model |
| TS inference | ◐ | Inferred | — | — | GraphQL codegen from the schema; a build step, not inference. | #nhost-ts_inference |
| Transactions | mvcc | Inferred | — | — | Standard Postgres underneath. | #nhost-transaction_semantics |
| Local-first sync | ○ | Inferred | — | — | — | #nhost-local_first_sync |
| Optimistic writes | ○ | Inferred | — | — | Whatever your GraphQL client offers. | #nhost-optimistic_updates |
| Cron & scheduling | ● | Inferred | — | — | Hasura scheduled and cron triggers. | #nhost-scheduled_functions |
| File storage | ● | Vendor-claimed | 2026-07-20 | https://docs.nhost.io/products/storage | — | #nhost-file_storage |
| Vector search | ● | Inferred | — | — | pgvector on the managed Postgres. | #nhost-vector_search |
| Full-text search | ● | Inferred | — | — | Postgres tsvector. | #nhost-full_text_search |
| Auth | built-in | Vendor-claimed | 2026-07-20 | https://docs.nhost.io/products/auth | — | #nhost-auth_included |
| Hard limits | Postgres limits, plus Hasura's own query-depth and rate limiting on the managed tiers. | Inferred | — | — | — | #nhost-hard_limits |
| Cold start | — | Unknown | — | — | Node function cold start not verified. | #nhost-cold_start |
| Function timeout | — | Unknown | — | — | — | #nhost-function_timeout |
| Exit cost | 2 | Inferred | — | — | Postgres plus open-source Hasura. Lift the database with pg_dump and run Hasura yourself, and the GraphQL documents in your app keep working — a genuinely cheap exit that few people notice. | #nhost-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://docs.nhost.io/platform/self-hosting | — | #nhost-self_hostable |
| Bulk export | ● | Inferred | — | — | Direct Postgres access. | #nhost-bulk_export |
| Raw SQL | ● | Inferred | — | — | — | #nhost-raw_sql |
| Schema changes | sql-migrations | Inferred | — | — | Hasura migrations plus metadata, both versioned in your repo. | #nhost-schema_migrations |
| MCP server | ● | Inferred | — | — | An MCP server is published; coverage not verified. | #nhost-mcp_server |
| Agent fit | 3 | Inferred | — | — | Schema and metadata live in the repo, which helps, but GraphQL codegen and Hasura permissions add moving parts an agent must keep in sync. | #nhost-agent_fit |
| Pricing model | flat per project + usage | Inferred | — | https://nhost.io/pricing | — | #nhost-pricing_model |
| Entry price | $25 /mo | Inferred | — | https://nhost.io/pricing | Pro tier, per project. Verify — Nhost has re-cut its plans more than once. | #nhost-entry_price |
| Egress metered | ● | Inferred | — | — | — | #nhost-egress_billing |
| GitHub stars | 8,000 | Inferred | — | — | Approximate as of mid-2026. | #nhost-github_stars |
| Backing | venture-backed | Inferred | — | — | — | #nhost-backing |
| Positioning | The open-source Firebase alternative, with GraphQL. | Vendor-claimed | 2026-07-20 | https://nhost.io | — | #nhost-positioning |

**Verdict.** An underrated exit: Postgres plus open-source Hasura means both halves of the stack survive leaving. It is also the quietest project here, which you should weigh against how much you like GraphQL.

**Pick it when**

- Teams already committed to GraphQL and Hasura
- Projects wanting managed convenience with a fully open stack underneath
- Anyone who wants Supabase's portability but prefers subscriptions to change feeds

### Zero {#rocicorp-zero}

Sync engine that puts a queryable client cache in front of your own Postgres.

|  |  |
| --- | --- |
| Site | https://zero.rocicorp.dev |
| Docs | https://zero.rocicorp.dev/docs |
| Repo | https://github.com/rocicorp/mono |
| Company | Rocicorp |
| Founded | 2019 |
| Funding | Venture-backed |
| Open source | Yes |
| Profile | https://toolweight.dev/tools/rocicorp-zero |
| Score (default weights) | 70.9 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://zero.rocicorp.dev/docs | ZQL queries resolve from a client-side cache and update as zero-cache replicates changes out of Postgres. | #rocicorp-zero-reactivity_model |
| TS inference | ● | Vendor-claimed | 2026-07-20 | https://zero.rocicorp.dev/docs/zero-schema | Schema defined in TypeScript, inferred through ZQL results. | #rocicorp-zero-ts_inference |
| Transactions | mvcc | Inferred | — | — | Custom mutators run server-side inside a real Postgres transaction; the client applies a speculative version first. | #rocicorp-zero-transaction_semantics |
| Local-first sync | ● | Vendor-claimed | 2026-07-20 | https://zero.rocicorp.dev/docs | — | #rocicorp-zero-local_first_sync |
| Optimistic writes | ● | Vendor-claimed | 2026-07-20 | https://zero.rocicorp.dev/docs | Speculative mutations with server rebase — the core of the design, not an add-on. | #rocicorp-zero-optimistic_updates |
| Cron & scheduling | ○ | Inferred | — | — | Not a backend; bring your own. | #rocicorp-zero-scheduled_functions |
| File storage | ○ | Inferred | — | — | — | #rocicorp-zero-file_storage |
| Vector search | ◐ | Inferred | — | — | Whatever your own Postgres has; Zero does not sync it. | #rocicorp-zero-vector_search |
| Full-text search | ◐ | Inferred | — | — | Available in your Postgres, outside the sync path. | #rocicorp-zero-full_text_search |
| Auth | bring-your-own | Vendor-claimed | 2026-07-20 | https://zero.rocicorp.dev/docs/auth | Verifies your JWT; permissions are declared against its claims. | #rocicorp-zero-auth_included |
| Hard limits | Client cache size is the practical ceiling — the query set you sync has to fit on the device. | Inferred | — | — | — | #rocicorp-zero-hard_limits |
| Cold start | — | Unknown | — | — | zero-cache is a long-running process you operate. | #rocicorp-zero-cold_start |
| Function timeout | — | Unknown | — | — | Mutators run on your own server. | #rocicorp-zero-function_timeout |
| Exit cost | 3 | Inferred | — | — | Your Postgres is never given up: schema, data and writes stay in SQL you own. Leaving means deleting the sync layer and rewriting the read path from ZQL back to queries — real work, but it never touches your data model. | #rocicorp-zero-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://zero.rocicorp.dev/docs/deployment | Self-hosting zero-cache is the primary deployment model. | #rocicorp-zero-self_hostable |
| Bulk export | ● | Inferred | — | — | It is your Postgres. | #rocicorp-zero-bulk_export |
| Raw SQL | ● | Inferred | — | — | Directly against your own database, though writes should go through mutators to stay consistent with connected clients. | #rocicorp-zero-raw_sql |
| Schema changes | sql-migrations | Inferred | — | — | Your own Postgres migrations, plus a Zero schema that has to be kept in step. | #rocicorp-zero-schema_migrations |
| MCP server | ○ | Inferred | — | — | — | #rocicorp-zero-mcp_server |
| Agent fit | 3 | Inferred | — | — | Typed and in-repo, but the operational surface — replication, cache deployment — is not something an agent finishes alone. | #rocicorp-zero-agent_fit |
| Pricing model | free (self-host) | Inferred | — | — | You pay for the machines running zero-cache and Postgres. | #rocicorp-zero-pricing_model |
| Entry price | $0 /mo | Inferred | — | — | No hosted product priced at time of writing; costs are infrastructure. | #rocicorp-zero-entry_price |
| Egress metered | ○ | Inferred | — | — | Your infrastructure, your bandwidth bill. | #rocicorp-zero-egress_billing |
| GitHub stars | 3,000 | Inferred | — | — | rocicorp/mono, approximate as of mid-2026. | #rocicorp-zero-github_stars |
| Backing | venture-backed | Inferred | — | — | — | #rocicorp-zero-backing |
| Positioning | A general-purpose sync engine for the web. | Vendor-claimed | 2026-07-20 | https://zero.rocicorp.dev | — | #rocicorp-zero-positioning |

**Verdict.** The most interesting shape on this page: instant local reads without surrendering the database. You still operate zero-cache and Postgres yourself, and you get no auth, storage or cron — this is a layer, not a platform.

**Pick it when**

- Teams with an existing Postgres who want a UI that feels local
- Apps where snappy reads matter but ownership of the data model is non-negotiable
- Adding sync incrementally rather than rewriting onto a backend platform

### PocketBase {#pocketbase}

One Go binary: SQLite database, auth, file storage, realtime and an admin UI.

|  |  |
| --- | --- |
| Site | https://pocketbase.io |
| Docs | https://pocketbase.io/docs/ |
| Repo | https://github.com/pocketbase/pocketbase |
| Company | PocketBase |
| Founded | 2022 |
| Open source | Yes (MIT) |
| Profile | https://toolweight.dev/tools/pocketbase |
| Score (default weights) | 66.6 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://pocketbase.io/docs/api-realtime/ | Server-sent events on collection changes. | #pocketbase-reactivity_model |
| TS inference | ◐ | Community-reported | — | — | The SDK is typed; collection types come from community typegen tools, not first-party inference. | #pocketbase-ts_inference |
| Transactions | serialisable | Inferred | — | — | SQLite in WAL mode: one writer at a time, commits serialised. Fine until write concurrency is the bottleneck. | #pocketbase-transaction_semantics |
| Local-first sync | ○ | Inferred | — | — | — | #pocketbase-local_first_sync |
| Optimistic writes | ○ | Inferred | — | — | — | #pocketbase-optimistic_updates |
| Cron & scheduling | ◐ | Inferred | — | — | Cron jobs are available from Go or the embedded JS hooks; there is no managed scheduler product. | #pocketbase-scheduled_functions |
| File storage | ● | Vendor-claimed | 2026-07-20 | https://pocketbase.io/docs/files-handling/ | Local disk or any S3-compatible bucket. | #pocketbase-file_storage |
| Vector search | ○ | Inferred | — | — | — | #pocketbase-vector_search |
| Full-text search | ◐ | Inferred | — | — | Filter expressions with LIKE. SQLite FTS is reachable from hooks but not exposed through the collection API. | #pocketbase-full_text_search |
| Auth | built-in | Vendor-claimed | 2026-07-20 | https://pocketbase.io/docs/authentication/ | — | #pocketbase-auth_included |
| Hard limits | One machine. SQLite tops out near a billion bytes per value and a single concurrent writer; everything else is your disk and RAM. | Inferred | — | — | — | #pocketbase-hard_limits |
| Cold start | 0 ms | Inferred | — | — | One always-on process; there is nothing to spin up. | #pocketbase-cold_start |
| Function timeout | — | Unknown | — | — | Hooks run in your own process — no platform-imposed ceiling. | #pocketbase-function_timeout |
| Exit cost | 3 | Inferred | — | — | The data is a SQLite file you already have, which is the cheapest extraction on this page. The rewrite is the client SDK and the collection rules DSL, which touch every call site. | #pocketbase-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://pocketbase.io/docs/going-to-production/ | Self-hosting is the only option; there is no vendor cloud. | #pocketbase-self_hostable |
| Bulk export | ● | Inferred | — | — | Copy the SQLite file. | #pocketbase-bulk_export |
| Raw SQL | ● | Inferred | — | — | Available from Go and JS hooks, and directly against the file. | #pocketbase-raw_sql |
| Schema changes | declarative-push | Vendor-claimed | 2026-07-20 | https://pocketbase.io/docs/go-migrations/ | Console edits auto-generate migration files you commit. | #pocketbase-schema_migrations |
| MCP server | ○ | Inferred | — | — | No official server; community implementations exist. | #pocketbase-mcp_server |
| Agent fit | 3 | Inferred | — | — | A single binary and a local database are easy for an agent to drive, but the schema lives in the admin UI. | #pocketbase-agent_fit |
| Pricing model | free (self-host only) | Vendor-claimed | 2026-07-20 | https://pocketbase.io | — | #pocketbase-pricing_model |
| Entry price | $0 /mo | Vendor-claimed | 2026-07-20 | https://pocketbase.io | MIT-licensed software; your only cost is the box, realistically a $5 VPS. | #pocketbase-entry_price |
| Egress metered | ○ | Inferred | — | — | Whatever your host charges you. | #pocketbase-egress_billing |
| GitHub stars | 48,000 | Inferred | — | — | Approximate as of mid-2026. | #pocketbase-github_stars |
| Backing | solo-maintainer | Community-reported | — | — | Primarily one maintainer. So far that has been a stability advantage rather than a liability. | #pocketbase-backing |
| Positioning | Open-source backend in one file. | Vendor-claimed | 2026-07-20 | https://pocketbase.io | — | #pocketbase-positioning |

**Verdict.** Absurdly good value for single-machine workloads, and the easiest data extraction here — the store is a file you own. The ceiling is real: one writer, one box, and a bus factor of roughly one.

**Pick it when**

- Internal tools and side projects where one VPS is plenty
- Anyone who wants the entire backend to be a file they can copy
- Air-gapped or on-premises deployments

### Convex {#convex}

Reactive TypeScript backend: database, functions and live queries in one project.

|  |  |
| --- | --- |
| Site | https://www.convex.dev |
| Docs | https://docs.convex.dev |
| Repo | https://github.com/get-convex/convex-backend |
| Company | Convex, Inc. |
| Founded | 2021 |
| Funding | Venture-backed |
| Open source | Yes (FSL-1.1-Apache-2.0) |
| Profile | https://toolweight.dev/tools/convex |
| Score (default weights) | 65.5 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/functions/query-functions | Query results are invalidated and re-pushed by the server when a dependent write commits; no subscription code. | #convex-reactivity_model |
| TS inference | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/database/schemas | — | #convex-ts_inference |
| Transactions | occ | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/database/advanced/occ | Optimistic concurrency with automatic retries; mutations are serialisable in effect. | #convex-transaction_semantics |
| Local-first sync | ○ | Inferred | — | — | Optimistic updates and a live cache, but no offline query engine or write reconciliation. | #convex-local_first_sync |
| Optimistic writes | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/client/react/optimistic-updates | — | #convex-optimistic_updates |
| Cron & scheduling | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/scheduling | Declarative crons plus one-off scheduling from inside mutations. | #convex-scheduled_functions |
| File storage | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/file-storage | — | #convex-file_storage |
| Vector search | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/search/vector-search | — | #convex-vector_search |
| Full-text search | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/search | — | #convex-full_text_search |
| Auth | first-party-addon | Inferred | — | — | Convex Auth is an official library you install; Clerk and Auth0 remain first-class integrations. | #convex-auth_included |
| Hard limits | 1 MiB per document; roughly 16k documents or 8 MiB scanned per query; queries and mutations capped near 1s of compute. | Inferred | — | https://docs.convex.dev/production/state/limits | Approximate — re-verify against the limits page before designing around them. | #convex-hard_limits |
| Cold start | 0 ms | Inferred | — | — | Functions run in a warm V8 isolate pool; no user-visible cold path on paid tiers. | #convex-cold_start |
| Function timeout | 10 min | Inferred | — | — | Actions get roughly 10 minutes. Queries and mutations are capped near 1 second — the headline does not apply to database work. | #convex-function_timeout |
| Exit cost | 4 | Inferred | — | — | Proprietary query builder plus proprietary runtime. Data exports cleanly via `npx convex export`, but every read, write, subscription and the reactive render model is rewritten. Self-hosting bounds vendor risk, not exit cost. | #convex-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/self-hosting | convex-backend is FSL-1.1-Apache-2.0: the licence converts to Apache-2.0 on a delay and restricts running it as a competing service. | #convex-self_hostable |
| Bulk export | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/database/import-export/ | `npx convex export` produces a zip of JSONL per table, self-serve. | #convex-bulk_export |
| Raw SQL | ○ | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/database | — | #convex-raw_sql |
| Schema changes | declarative-push | Inferred | — | — | schema.ts is diffed and validated on deploy; data backfills are hand-written mutations. | #convex-schema_migrations |
| MCP server | ● | Vendor-claimed | 2026-07-20 | https://docs.convex.dev/ai/convex-mcp-server | — | #convex-mcp_server |
| Agent fit | 5 | Inferred | — | — | Schema, functions and client types in one repo, a local dev loop, and type errors that point at the fix. The best agent target on this page. | #convex-agent_fit |
| Pricing model | per-seat + usage | Vendor-claimed | 2026-07-20 | https://www.convex.dev/pricing | — | #convex-pricing_model |
| Entry price | $25 /mo | Vendor-claimed | 2026-07-20 | https://www.convex.dev/pricing | Professional is priced per team member, so a five-person team starts at five times this before usage. | #convex-entry_price |
| Egress metered | ● | Vendor-claimed | 2026-07-20 | https://www.convex.dev/pricing | Bandwidth is metered per GB beyond the included allowance. | #convex-egress_billing |
| GitHub stars | 8,000 | Inferred | — | — | convex-backend, approximate as of mid-2026. | #convex-github_stars |
| Backing | venture-backed | Inferred | — | — | — | #convex-backing |
| Positioning | The open-source reactive database for app developers. | Vendor-claimed | 2026-07-20 | https://www.convex.dev | — | #convex-positioning |

**Verdict.** The fastest path from empty repo to working realtime feature, and the clearest thinking about transactions on this page. It is also a 4 on exit cost with no SQL escape hatch — a bet worth making deliberately rather than by default.

**Pick it when**

- Small teams shipping realtime-shaped product fast
- Codebases where a coding agent does most of the plumbing
- Apps whose lifespan is short enough that the exit never arrives

### ElectricSQL {#electricsql}

Postgres read-path sync: stream subsets of your own database to clients over HTTP.

|  |  |
| --- | --- |
| Site | https://electric-sql.com |
| Docs | https://electric-sql.com/docs |
| Repo | https://github.com/electric-sql/electric |
| Company | ElectricSQL |
| Founded | 2021 |
| Funding | Venture-backed |
| Open source | Yes (Apache-2.0) |
| Profile | https://toolweight.dev/tools/electricsql |
| Score (default weights) | 62.0 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://electric-sql.com/docs/guides/shapes | Shapes stream over HTTP with long-polling semantics and CDN caching. Reads only. | #electricsql-reactivity_model |
| TS inference | ◐ | Inferred | — | — | Shape results are typed if you type them; there is no schema-to-client inference. | #electricsql-ts_inference |
| Transactions | mvcc | Inferred | — | — | Your Postgres. Electric never handles writes. | #electricsql-transaction_semantics |
| Local-first sync | ◐ | Vendor-claimed | 2026-07-20 | https://electric-sql.com/docs | Read-path sync only — writes go through your existing API, and reconciling them is your design problem. | #electricsql-local_first_sync |
| Optimistic writes | ◐ | Inferred | — | — | Documented patterns rather than a first-party API. | #electricsql-optimistic_updates |
| Cron & scheduling | ○ | Inferred | — | — | — | #electricsql-scheduled_functions |
| File storage | ○ | Inferred | — | — | — | #electricsql-file_storage |
| Vector search | ◐ | Inferred | — | — | Available in your Postgres; not part of Electric. | #electricsql-vector_search |
| Full-text search | ◐ | Inferred | — | — | Available in your Postgres; not part of Electric. | #electricsql-full_text_search |
| Auth | bring-your-own | Vendor-claimed | 2026-07-20 | https://electric-sql.com/docs/guides/auth | Shape requests are proxied through your own auth layer. | #electricsql-auth_included |
| Hard limits | Shape size — a shape has to be small enough to hold on the client and cheap enough to re-materialise on the server. | Inferred | — | — | — | #electricsql-hard_limits |
| Cold start | — | Unknown | — | — | Electric is a long-running sync service, not a function runtime. | #electricsql-cold_start |
| Function timeout | — | Unknown | — | — | No function runtime. | #electricsql-function_timeout |
| Exit cost | 2 | Inferred | — | — | The lightest commitment here. Your Postgres, schema, writes and API are untouched; removing Electric means replacing shape subscriptions with fetches. Nothing about your data model was ever Electric-shaped. | #electricsql-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://electric-sql.com/docs/guides/deployment | Apache-2.0; a single service beside your Postgres. | #electricsql-self_hostable |
| Bulk export | ● | Inferred | — | — | It is your Postgres. | #electricsql-bulk_export |
| Raw SQL | ● | Inferred | — | — | — | #electricsql-raw_sql |
| Schema changes | sql-migrations | Inferred | — | — | Your own migrations; Electric follows the logical replication stream. | #electricsql-schema_migrations |
| MCP server | ○ | Inferred | — | — | — | #electricsql-mcp_server |
| Agent fit | 2 | Inferred | — | — | A minimal surface, but the agent must still assemble the write path, auth proxy and client store — most of the app is not Electric. | #electricsql-agent_fit |
| Pricing model | free (self-host) + optional cloud | Inferred | — | https://electric-sql.com/pricing | — | #electricsql-pricing_model |
| Entry price | — | Unknown | — | — | Self-hosting is free under Apache-2.0. Electric Cloud has paid tiers whose current price was not verified. | #electricsql-entry_price |
| Egress metered | ◐ | Inferred | — | — | Self-hosted, your own bandwidth. On the cloud, data transferred is a billed dimension. | #electricsql-egress_billing |
| GitHub stars | 8,000 | Inferred | — | — | Approximate as of mid-2026. | #electricsql-github_stars |
| Backing | venture-backed | Inferred | — | — | — | #electricsql-backing |
| Positioning | Postgres sync engine — sync little subsets of your data into local apps. | Vendor-claimed | 2026-07-20 | https://electric-sql.com | — | #electricsql-positioning |

**Verdict.** The narrowest tool here and the best-behaved: read-path sync over a Postgres you already own, with an exit close to free. It solves a quarter of what Convex solves, and it is honest about which quarter.

**Pick it when**

- Existing Postgres apps that need live read data without a rewrite
- Teams that already have a write API they are happy with
- Anyone who wants sync without adopting a backend platform

### Neon + Drizzle {#neon-drizzle}

The DIY baseline: serverless Postgres, a typed SQL query builder, nothing else.

|  |  |
| --- | --- |
| Site | https://neon.com |
| Docs | https://orm.drizzle.team/docs/overview |
| Repo | https://github.com/drizzle-team/drizzle-orm |
| Company | Neon (Databricks) / Drizzle Team |
| Founded | 2021 |
| Funding | Acquired by Databricks, 2025 |
| Open source | Yes (Apache-2.0) |
| Profile | https://toolweight.dev/tools/neon-drizzle |
| Score (default weights) | 60.5 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | manual | Inferred | — | — | Nothing is pushed. LISTEN/NOTIFY exists, but you build the delivery. | #neon-drizzle-reactivity_model |
| TS inference | ● | Vendor-claimed | 2026-07-20 | https://orm.drizzle.team/docs/overview | Schema is TypeScript and query results are inferred, with no codegen step. | #neon-drizzle-ts_inference |
| Transactions | mvcc | Vendor-claimed | 2026-07-20 | https://neon.com/docs | Postgres, with every isolation level available. | #neon-drizzle-transaction_semantics |
| Local-first sync | ○ | Inferred | — | — | — | #neon-drizzle-local_first_sync |
| Optimistic writes | ○ | Inferred | — | — | — | #neon-drizzle-optimistic_updates |
| Cron & scheduling | ○ | Inferred | — | — | pg_cron on the database, but no application scheduler — you bring a worker. | #neon-drizzle-scheduled_functions |
| File storage | ○ | Inferred | — | — | Pair it with object storage yourself. | #neon-drizzle-file_storage |
| Vector search | ● | Vendor-claimed | 2026-07-20 | https://neon.com/docs/extensions/pgvector | pgvector. | #neon-drizzle-vector_search |
| Full-text search | ● | Inferred | — | — | Postgres tsvector. | #neon-drizzle-full_text_search |
| Auth | bring-your-own | Inferred | — | — | Neon has shipped auth adjacencies, but the baseline here assumes you supply it. | #neon-drizzle-auth_included |
| Hard limits | Postgres limits. The operational ceiling is your compute size and connection count, both dials you control. | Inferred | — | — | — | #neon-drizzle-hard_limits |
| Cold start | 500 ms | Vendor-claimed | 2026-07-20 | https://neon.com/docs/introduction/auto-suspend | Compute resume after auto-suspend; sub-second in practice. | #neon-drizzle-cold_start |
| Function timeout | — | Unknown | — | — | No function runtime — you run your own server. | #neon-drizzle-function_timeout |
| Exit cost | 1 | Inferred | — | — | The reference point. Standard Postgres over the wire and SQL you wrote yourself: leaving is a connection string and a pg_dump. Every other row on this page is scored against this one. | #neon-drizzle-exit_cost |
| Self-hostable | ◐ | Inferred | — | — | Neon's storage engine is Apache-2.0 but running it is a project. In practice you self-host by running ordinary Postgres — which is rather the point. | #neon-drizzle-self_hostable |
| Bulk export | ● | Inferred | — | — | — | #neon-drizzle-bulk_export |
| Raw SQL | ● | Inferred | — | — | — | #neon-drizzle-raw_sql |
| Schema changes | sql-migrations | Vendor-claimed | 2026-07-20 | https://orm.drizzle.team/docs/kit-overview | drizzle-kit generates reviewable SQL files. | #neon-drizzle-schema_migrations |
| MCP server | ● | Vendor-claimed | 2026-07-20 | https://neon.com/docs/ai/neon-mcp-server | — | #neon-drizzle-mcp_server |
| Agent fit | 4 | Inferred | — | — | Typed schema in-repo, real migration files, and a database branch per agent run. What it lacks is plumbing — the agent writes the API layer itself. | #neon-drizzle-agent_fit |
| Pricing model | flat + compute-hours + storage | Vendor-claimed | 2026-07-20 | https://neon.com/pricing | — | #neon-drizzle-pricing_model |
| Entry price | $19 /mo | Vendor-claimed | 2026-07-20 | https://neon.com/pricing | Launch plan, including an allowance of compute hours and storage. | #neon-drizzle-entry_price |
| Egress metered | ◐ | Inferred | — | — | Generous allowances rather than a per-GB line at small scale; verify at volume. | #neon-drizzle-egress_billing |
| GitHub stars | 18,000 | Inferred | — | — | neondatabase/neon, approximate as of mid-2026. | #neon-drizzle-github_stars |
| Backing | big-tech | Vendor-claimed | 2026-07-20 | https://neon.com/blog/neon-and-databricks | Acquired by Databricks in 2025. | #neon-drizzle-backing |
| Positioning | Serverless Postgres with branching, paired with a typed SQL query builder. | Vendor-claimed | 2026-07-20 | https://neon.com | — | #neon-drizzle-positioning |

**Verdict.** Not a competitor — the yardstick. You write the realtime layer, the auth, the file handling and the scheduler yourself, and in exchange nothing you build is owned by anyone else. Every exit-cost score here is measured against this row.

**Pick it when**

- Teams that already know what backend they want to build
- Applications expected to outlive several vendor relationships
- Anyone whose realtime requirement is smaller than it first appeared

### InstantDB {#instantdb}

Client-side reactive database with a relational graph model and instant sync.

|  |  |
| --- | --- |
| Site | https://www.instantdb.com |
| Docs | https://www.instantdb.com/docs |
| Repo | https://github.com/instantdb/instant |
| Company | InstantDB |
| Founded | 2022 |
| Funding | Venture-backed |
| Open source | Yes |
| Profile | https://toolweight.dev/tools/instantdb |
| Score (default weights) | 57.8 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://www.instantdb.com/docs | Queries resolve against a local store and update as the server syncs. | #instantdb-reactivity_model |
| TS inference | ● | Vendor-claimed | 2026-07-20 | https://www.instantdb.com/docs/modeling-data | Schema defined in TypeScript, inferred through InstaQL results. | #instantdb-ts_inference |
| Transactions | occ | Inferred | — | — | Transaction chunks apply atomically with server-side conflict detection. | #instantdb-transaction_semantics |
| Local-first sync | ● | Vendor-claimed | 2026-07-20 | https://www.instantdb.com/docs | — | #instantdb-local_first_sync |
| Optimistic writes | ● | Vendor-claimed | 2026-07-20 | https://www.instantdb.com/docs | Writes apply locally first by design; the default path, not an opt-in helper. | #instantdb-optimistic_updates |
| Cron & scheduling | ○ | Inferred | — | — | No server-side function runtime at all. | #instantdb-scheduled_functions |
| File storage | ● | Vendor-claimed | 2026-07-20 | https://www.instantdb.com/docs/storage | — | #instantdb-file_storage |
| Vector search | ○ | Inferred | — | — | — | #instantdb-vector_search |
| Full-text search | ○ | Inferred | — | — | — | #instantdb-full_text_search |
| Auth | built-in | Vendor-claimed | 2026-07-20 | https://www.instantdb.com/docs/auth | Magic codes plus OAuth providers. | #instantdb-auth_included |
| Hard limits | — | Unknown | — | — | No published per-record or per-query ceilings found. | #instantdb-hard_limits |
| Cold start | — | Unknown | — | — | No user-supplied function runtime to cold-start. | #instantdb-cold_start |
| Function timeout | — | Unknown | — | — | No server functions. | #instantdb-function_timeout |
| Exit cost | 4 | Inferred | — | — | InstaQL is a proprietary graph query language over a triple store with no SQL surface, and the local-first behaviour your UI depends on has no drop-in replacement. Open source lowers vendor risk, not the rewrite. | #instantdb-exit_cost |
| Self-hostable | ◐ | Community-reported | — | — | The server is open source, but running it yourself is materially harder than using the cloud. | #instantdb-self_hostable |
| Bulk export | ◐ | Inferred | — | — | Admin SDK queries can page everything out; there is no single self-serve dump. | #instantdb-bulk_export |
| Raw SQL | ○ | Inferred | — | — | — | #instantdb-raw_sql |
| Schema changes | declarative-push | Vendor-claimed | 2026-07-20 | https://www.instantdb.com/docs/modeling-data | CLI pushes the TypeScript schema. | #instantdb-schema_migrations |
| MCP server | ● | Inferred | — | — | An official MCP server is published for agent-driven app creation. | #instantdb-mcp_server |
| Agent fit | 4 | Inferred | — | — | A tiny typed surface an agent can hold in context, but with no server-side logic to write, some features cannot be finished on the backend at all. | #instantdb-agent_fit |
| Pricing model | flat + usage | Inferred | — | https://www.instantdb.com/pricing | — | #instantdb-pricing_model |
| Entry price | $30 /mo | Inferred | — | https://www.instantdb.com/pricing | Approximate — the Pro tier has moved; verify before budgeting. | #instantdb-entry_price |
| Egress metered | — | Unknown | — | — | — | #instantdb-egress_billing |
| GitHub stars | 9,000 | Inferred | — | — | Approximate as of mid-2026. | #instantdb-github_stars |
| Backing | venture-backed | Inferred | — | — | — | #instantdb-backing |
| Positioning | A modern Firebase — a client-side database that syncs. | Vendor-claimed | 2026-07-20 | https://www.instantdb.com | — | #instantdb-positioning |

**Verdict.** The most pleasant developer experience here for collaborative, instant-feeling UIs, and the smallest API surface. The absence of any server-side function runtime is the constraint people hit, usually around the third feature.

**Pick it when**

- Multiplayer or collaborative UIs where every interaction must feel local
- Front-end-heavy teams with no appetite for backend infrastructure
- Prototypes that need presence, cursors and live editing on day one

### Appwrite {#appwrite}

Open-source backend platform: databases, auth, storage, functions, self-hostable.

|  |  |
| --- | --- |
| Site | https://appwrite.io |
| Docs | https://appwrite.io/docs |
| Repo | https://github.com/appwrite/appwrite |
| Company | Appwrite |
| Founded | 2019 |
| Funding | Venture-backed |
| Open source | Yes (BSD-3-Clause) |
| Profile | https://toolweight.dev/tools/appwrite |
| Score (default weights) | 54.6 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://appwrite.io/docs/apis/realtime | Websocket subscription to document and file events, not to query results. | #appwrite-reactivity_model |
| TS inference | ◐ | Inferred | — | — | SDKs are typed and the CLI can generate types from your collections, but the schema lives in the console rather than your repo. | #appwrite-ts_inference |
| Transactions | none | Inferred | — | — | Historically no general multi-document transaction primitive in the public API, though transaction support has been in flight. The least confident cell in this row — re-verify. | #appwrite-transaction_semantics |
| Local-first sync | ○ | Inferred | — | — | — | #appwrite-local_first_sync |
| Optimistic writes | ○ | Inferred | — | — | — | #appwrite-optimistic_updates |
| Cron & scheduling | ● | Vendor-claimed | 2026-07-20 | https://appwrite.io/docs/products/functions | Cron schedules attached to functions. | #appwrite-scheduled_functions |
| File storage | ● | Vendor-claimed | 2026-07-20 | https://appwrite.io/docs/products/storage | — | #appwrite-file_storage |
| Vector search | ○ | Inferred | — | — | — | #appwrite-vector_search |
| Full-text search | ◐ | Inferred | — | — | Fulltext indexes on string attributes via the underlying MariaDB; no meaningful relevance ranking. | #appwrite-full_text_search |
| Auth | built-in | Vendor-claimed | 2026-07-20 | https://appwrite.io/docs/products/auth | Unusually broad OAuth provider list. | #appwrite-auth_included |
| Hard limits | Attribute count per collection is bounded by the underlying MariaDB row width — wide documents fail at creation time rather than at scale. | Inferred | — | — | — | #appwrite-hard_limits |
| Cold start | 1 s | Inferred | — | — | Function containers spin up per invocation unless kept warm; order of a second. | #appwrite-cold_start |
| Function timeout | 15 min | Inferred | — | — | Cloud maximum; the default is far lower and set per function. | #appwrite-function_timeout |
| Exit cost | 3 | Inferred | — | — | Open source and self-hostable, and if you host it you own the MariaDB underneath. But every read and write goes through Appwrite's SDK and permissions model, so the client rewrite is total even though the data is free. | #appwrite-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://appwrite.io/docs/advanced/self-hosting | — | #appwrite-self_hostable |
| Bulk export | ◐ | Inferred | — | — | Self-hosted, you dump MariaDB. On Cloud you paginate collections through the API yourself. | #appwrite-bulk_export |
| Raw SQL | ○ | Inferred | — | — | MariaDB is an implementation detail; the API does not expose it. | #appwrite-raw_sql |
| Schema changes | declarative-push | Inferred | — | — | appwrite.json plus CLI push, though the console remains the path of least resistance. | #appwrite-schema_migrations |
| MCP server | ● | Vendor-claimed | 2026-07-20 | https://appwrite.io/docs/tooling/mcp | — | #appwrite-mcp_server |
| Agent fit | 3 | Inferred | — | — | Good SDK coverage, but console-first configuration means an agent cannot see or change the schema from the repo alone. | #appwrite-agent_fit |
| Pricing model | per-seat + usage | Vendor-claimed | 2026-07-20 | https://appwrite.io/pricing | — | #appwrite-pricing_model |
| Entry price | $15 /mo | Vendor-claimed | 2026-07-20 | https://appwrite.io/pricing | Pro is priced per member per month. | #appwrite-entry_price |
| Egress metered | ● | Vendor-claimed | 2026-07-20 | https://appwrite.io/pricing | Bandwidth metered beyond the plan allowance. | #appwrite-egress_billing |
| GitHub stars | 52,000 | Inferred | — | — | Approximate as of mid-2026. | #appwrite-github_stars |
| Backing | venture-backed | Inferred | — | — | — | #appwrite-backing |
| Positioning | Build like a team of hundreds — an open-source backend platform. | Vendor-claimed | 2026-07-20 | https://appwrite.io | — | #appwrite-positioning |

**Verdict.** The most complete self-hostable batteries-included option, with the widest OAuth and SDK coverage here. Held back by a console-first model that keeps your schema out of your repo, and by the weakest transaction story on the page.

**Pick it when**

- Teams that must run the whole backend on their own infrastructure
- Apps with many client platforms — the SDK matrix is the broadest here
- Products where auth provider breadth matters more than query power

### Firebase {#firebase}

Google's app platform: Firestore documents, auth, functions, deep mobile SDKs.

|  |  |
| --- | --- |
| Site | https://firebase.google.com |
| Docs | https://firebase.google.com/docs |
| Company | Google |
| Founded | 2011 |
| Open source | No |
| Profile | https://toolweight.dev/tools/firebase |
| Score (default weights) | 51.2 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/firestore/query-data/listen | Per-query snapshot listeners with delta updates — the original, and still very good. | #firebase-reactivity_model |
| TS inference | ○ | Inferred | — | — | Firestore is schemaless; converters are hand-written. | #firebase-ts_inference |
| Transactions | occ | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/firestore/manage-data/transactions | Client SDKs use optimistic concurrency with retries; server SDKs take pessimistic locks. Bounded to 500 writes per transaction. | #firebase-transaction_semantics |
| Local-first sync | ◐ | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/firestore/manage-data/enable-offline | Real offline persistence with local query evaluation and a write queue; conflict resolution is last-write-wins. | #firebase-local_first_sync |
| Optimistic writes | ● | Inferred | — | — | Local writes hit listeners immediately, before the server acknowledges. | #firebase-optimistic_updates |
| Cron & scheduling | ● | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/functions/schedule-functions | — | #firebase-scheduled_functions |
| File storage | ● | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/storage | — | #firebase-file_storage |
| Vector search | ● | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/firestore/vector-search | — | #firebase-vector_search |
| Full-text search | ○ | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/firestore/solutions/search | The documented answer is to attach Algolia or Elastic. | #firebase-full_text_search |
| Auth | built-in | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/auth | — | #firebase-auth_included |
| Hard limits | 1 MiB per document; about one sustained write per second per document; 500 operations per transaction; no joins. | Inferred | — | — | The write-per-document ceiling is the one that reshapes real schemas. | #firebase-hard_limits |
| Cold start | 2 s | Community-reported | — | — | Node Cloud Functions cold start, commonly 1–3s. Minimum instances remove it for a fee. | #firebase-cold_start |
| Function timeout | 60 min | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/functions/quotas | 60 minutes for 2nd-gen HTTP functions; event-driven functions cap at 9 minutes. | #firebase-function_timeout |
| Exit cost | 5 | Inferred | — | — | Proprietary query API, proprietary runtime, a proprietary rules language, no self-host, and a managed export format only Firestore's importer reads. Getting the data out is its own project before the rewrite starts. | #firebase-exit_cost |
| Self-hostable | ○ | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs | The local emulator suite is for development only. | #firebase-self_hostable |
| Bulk export | ◐ | Inferred | — | — | Managed export writes a format only Firestore reads. An open dump means paginating collections through the Admin SDK yourself. | #firebase-bulk_export |
| Raw SQL | ○ | Inferred | — | — | — | #firebase-raw_sql |
| Schema changes | schemaless | Inferred | — | — | No schema to migrate; shape changes are handled in application code and backfill scripts. | #firebase-schema_migrations |
| MCP server | ● | Vendor-claimed | 2026-07-20 | https://firebase.google.com/docs/cli/mcp-server | — | #firebase-mcp_server |
| Agent fit | 2 | Inferred | — | — | Untyped documents, console-configured indexes and a string rules DSL give an agent very little to check itself against. | #firebase-agent_fit |
| Pricing model | usage only (Blaze pay-as-you-go) | Vendor-claimed | 2026-07-20 | https://firebase.google.com/pricing | — | #firebase-pricing_model |
| Entry price | $0 /mo | Vendor-claimed | 2026-07-20 | https://firebase.google.com/pricing | No base fee on Blaze; you pay per read, write, delete, GB stored and GB out. | #firebase-entry_price |
| Egress metered | ● | Vendor-claimed | 2026-07-20 | https://firebase.google.com/pricing | — | #firebase-egress_billing |
| GitHub stars | — | Unknown | — | — | Closed product; the JS SDK repository is not a meaningful proxy. | #firebase-github_stars |
| Backing | big-tech | Inferred | — | — | — | #firebase-backing |
| Positioning | Google's platform for building and running app backends. | Vendor-claimed | 2026-07-20 | https://firebase.google.com | — | #firebase-positioning |

**Verdict.** Still the best offline story and the best mobile SDKs, and still the worst exit on this page by a distance. Reasonable for consumer apps that will never migrate; a liability for anything you expect to restructure later.

**Pick it when**

- Consumer mobile apps where offline behaviour is the product
- Teams already inside Google Cloud with the operational habits to match
- Prototypes that will be thrown away rather than migrated

### Triplit {#triplit}

Full-stack database that syncs: local cache, server, relational queries, offline.

|  |  |
| --- | --- |
| Site | https://www.triplit.dev |
| Docs | https://www.triplit.dev/docs |
| Repo | https://github.com/aspen-cloud/triplit |
| Company | Triplit |
| Founded | 2023 |
| Open source | Yes |
| Profile | https://toolweight.dev/tools/triplit |
| Score (default weights) | 50.4 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Reactivity | push | Vendor-claimed | 2026-07-20 | https://www.triplit.dev/docs | Subscriptions to relational queries, resolved against the local cache first. | #triplit-reactivity_model |
| TS inference | ● | Vendor-claimed | 2026-07-20 | https://www.triplit.dev/docs/schemas | Schema in TypeScript, inferred through the query builder. | #triplit-ts_inference |
| Transactions | occ | Inferred | — | — | Client transactions apply locally then reconcile server-side. | #triplit-transaction_semantics |
| Local-first sync | ● | Vendor-claimed | 2026-07-20 | https://www.triplit.dev/docs | Offline-capable local store with partial replication. | #triplit-local_first_sync |
| Optimistic writes | ● | Vendor-claimed | 2026-07-20 | https://www.triplit.dev/docs | — | #triplit-optimistic_updates |
| Cron & scheduling | ○ | Inferred | — | — | — | #triplit-scheduled_functions |
| File storage | ○ | Inferred | — | — | — | #triplit-file_storage |
| Vector search | ○ | Inferred | — | — | — | #triplit-vector_search |
| Full-text search | ○ | Inferred | — | — | — | #triplit-full_text_search |
| Auth | bring-your-own | Inferred | — | — | Verifies a JWT you issue elsewhere; rules are written against its claims. | #triplit-auth_included |
| Hard limits | — | Unknown | — | — | No published record or query ceilings found. | #triplit-hard_limits |
| Cold start | — | Unknown | — | — | No user function runtime. | #triplit-cold_start |
| Function timeout | — | Unknown | — | — | — | #triplit-function_timeout |
| Exit cost | 4 | Inferred | — | — | A triple store with its own query builder and no SQL surface, and the offline sync your UI relies on has no equivalent to swap in. Self-hostable, which caps vendor risk, but the client rewrite is complete. | #triplit-exit_cost |
| Self-hostable | ● | Vendor-claimed | 2026-07-20 | https://www.triplit.dev/docs/self-hosting | — | #triplit-self_hostable |
| Bulk export | ◐ | Inferred | — | — | Scriptable through the admin API; no documented one-shot dump. | #triplit-bulk_export |
| Raw SQL | ○ | Inferred | — | — | — | #triplit-raw_sql |
| Schema changes | declarative-push | Vendor-claimed | 2026-07-20 | https://www.triplit.dev/docs/schemas | — | #triplit-schema_migrations |
| MCP server | ○ | Inferred | — | — | — | #triplit-mcp_server |
| Agent fit | 3 | Inferred | — | — | Fully typed and in-repo, which agents like; a thin documentation corpus, which they do not. | #triplit-agent_fit |
| Pricing model | — | Unknown | — | — | Hosted pricing not verified. | #triplit-pricing_model |
| Entry price | — | Unknown | — | — | Self-hosting is free; the hosted tier's current price was not confirmed. | #triplit-entry_price |
| Egress metered | — | Unknown | — | — | — | #triplit-egress_billing |
| GitHub stars | 4,000 | Inferred | — | — | Approximate as of mid-2026. | #triplit-github_stars |
| Backing | venture-backed | Inferred | — | — | Small team; treat continuity as a real risk factor. | #triplit-backing |
| Positioning | The full-stack database that syncs. | Vendor-claimed | 2026-07-20 | https://www.triplit.dev | — | #triplit-positioning |

**Verdict.** Technically the most elegant local-first model here — typed relational queries over a triple store, with real partial replication. Also the smallest team on the page, with no storage, no auth and no functions around it.

**Pick it when**

- Offline-first apps that need relational queries rather than document blobs
- Teams happy to supply their own auth and file handling
- Projects where sync correctness matters more than ecosystem size

## Methodology

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.

## FAQ

### Is Convex a good idea if I might need to leave later?

Only if you price the exit now. Convex has no SQL surface, so every query, mutation and subscription is rewritten on the way out, and the reactive render model has no drop-in equivalent. That is a 4 out of 5 on our exit-cost ladder. If the codebase is likely to outlive the decision and you are not certain, start on Postgres instead.

### Does self-hosting Convex remove the lock-in?

No — it removes vendor risk, which is a different problem. The convex-backend repository is open under FSL-1.1-Apache-2.0 and self-hosting is documented, so Convex disappearing cannot strand you. But a self-hosted Convex still speaks the Convex query API, so the cost of moving your application to something that is not Convex is unchanged. Exit cost and vendor risk are separate columns for a reason.

### Supabase or Convex for a new TypeScript app?

Convex if the app is realtime-shaped and the team is small — you will ship the first version faster and write no subscription plumbing. Supabase if you want the data to stay in Postgres, need raw SQL, or expect analytics and BI tools to read the same database. The productivity gap is real but narrower than it was; the portability gap is not narrowing at all.

### What is the actual difference between Zero and ElectricSQL?

Direction and scope. Electric streams read-only shapes out of your Postgres over HTTP and says nothing about writes — you keep your own API. Zero syncs queries into a client-side cache and handles writes through custom mutators that run against your Postgres, so it owns more of the loop. Electric is the smaller commitment; Zero gives you more in return for it.

### Is Firebase still a reasonable default in 2026?

For consumer mobile apps that will never migrate, yes — the SDKs, offline persistence and Google's operations remain hard to beat. For anything else it is the worst exit on this page: no self-host, a proprietary rules language, an export format only Firestore reads, and a document model that shapes your schema around its query engine. Choose it deliberately, not by habit.

### Which of these is genuinely local-first?

InstantDB, Triplit and Zero, with ElectricSQL covering the read half. All four keep a real client-side store, resolve queries locally and reconcile with the server. Firebase's offline persistence gets close for simple cases. Convex and Supabase are not local-first: they are fast realtime backends with optimistic-update helpers, which is a different guarantee once the network is gone.

### How should a small team weight exit cost against speed?

By expected lifespan. Under twelve months and pre-product-market-fit, exit cost is nearly free and shipping speed is everything — take Convex or Instant. Past that, rewriting an entire data layer is measured in engineer-months and the Postgres options claw it back. The honest framing is that Convex charges its fee at the end, in one payment, and you cannot pay it early.

## Recent changes

| Date | Kind | Event | Tools | Source |
| --- | --- | --- | --- | --- |
| 2025-01-15 | launch | **Convex ships supported self-hosting** — Convex published a documented self-hosting path for the open-source convex-backend, moving it from a repository you could compile to a deployment target the company supports. It bounds vendor risk without changing the exit-cost picture: a self-hosted Convex is still Convex. | convex | https://docs.convex.dev/self-hosting |
| 2025-03-17 | launch | **ElectricSQL reaches 1.0** — Electric declared its Postgres sync engine production-ready after a rewrite that dropped the embedded client database in favour of HTTP shape streams. The narrowing — read path only, writes stay in your API — is what makes it the cheapest thing on this page to remove later. | electricsql | https://electric-sql.com/blog |
| 2025-04-22 | funding | **Supabase raises a large Series D** — Supabase announced a round reported at around US$200m at a multi-billion-dollar valuation, cementing it as the default managed-Postgres platform for application developers. The practical effect for buyers: the Postgres-native option on this list is the least likely to disappear. | supabase | https://supabase.com/blog |
| 2025-05-14 | funding | **Databricks agrees to acquire Neon** — Databricks announced an agreement to acquire Neon in a deal reported at roughly US$1bn, citing agent-driven database provisioning as the motivation. Neon's branching remains the best fit here for per-agent database environments — now under a very different owner. | neon-drizzle | https://neon.com/blog/neon-and-databricks |
| 2025-05-20 | launch | **Google launches Firebase Studio** — At I/O 2025 Google put an agentic app builder in front of Firebase, generating Firestore schemas, rules and functions from prompts. It sharpens the trade Firebase has always offered: the fastest possible start, on the least portable stack in this comparison. | firebase | https://firebase.google.com/docs/studio |
| 2025-06-10 | launch | **Zero enters public beta** — Rocicorp moved Zero from invite-only alpha to public beta, with custom mutators as the supported write path. It is the clearest expression yet of the alternative to backend platforms: keep your Postgres, put a sync engine in front of it. | rocicorp-zero | https://zero.rocicorp.dev |

## Sources

| Source | Last verified |
| --- | --- |
| https://docs.convex.dev/functions/query-functions | 2026-07-20 |
| https://docs.convex.dev/database/schemas | 2026-07-20 |
| https://docs.convex.dev/database/advanced/occ | 2026-07-20 |
| https://docs.convex.dev/client/react/optimistic-updates | 2026-07-20 |
| https://docs.convex.dev/scheduling | 2026-07-20 |
| https://docs.convex.dev/file-storage | 2026-07-20 |
| https://docs.convex.dev/search/vector-search | 2026-07-20 |
| https://docs.convex.dev/search | 2026-07-20 |
| https://docs.convex.dev/production/state/limits | — |
| https://docs.convex.dev/self-hosting | 2026-07-20 |
| https://docs.convex.dev/database/import-export/ | 2026-07-20 |
| https://docs.convex.dev/database | 2026-07-20 |
| https://docs.convex.dev/ai/convex-mcp-server | 2026-07-20 |
| https://www.convex.dev/pricing | 2026-07-20 |
| https://www.convex.dev | 2026-07-20 |
| https://supabase.com/docs/guides/realtime | 2026-07-20 |
| https://supabase.com/docs/guides/api/rest/generating-types | 2026-07-20 |
| https://supabase.com/docs/guides/database | 2026-07-20 |
| https://supabase.com/docs/guides/cron | 2026-07-20 |
| https://supabase.com/docs/guides/storage | 2026-07-20 |
| https://supabase.com/docs/guides/ai | 2026-07-20 |
| https://supabase.com/docs/guides/database/full-text-search | 2026-07-20 |
| https://supabase.com/docs/guides/auth | 2026-07-20 |
| https://supabase.com/docs/guides/self-hosting | 2026-07-20 |
| https://supabase.com/docs/guides/database/connecting-to-postgres | 2026-07-20 |
| https://supabase.com/docs/guides/deployment/database-migrations | 2026-07-20 |
| https://supabase.com/docs/guides/getting-started/mcp | 2026-07-20 |
| https://supabase.com/pricing | 2026-07-20 |
| https://supabase.com | 2026-07-20 |
| https://firebase.google.com/docs/firestore/query-data/listen | 2026-07-20 |
| https://firebase.google.com/docs/firestore/manage-data/transactions | 2026-07-20 |
| https://firebase.google.com/docs/firestore/manage-data/enable-offline | 2026-07-20 |
| https://firebase.google.com/docs/functions/schedule-functions | 2026-07-20 |
| https://firebase.google.com/docs/storage | 2026-07-20 |
| https://firebase.google.com/docs/firestore/vector-search | 2026-07-20 |
| https://firebase.google.com/docs/firestore/solutions/search | 2026-07-20 |
| https://firebase.google.com/docs/auth | 2026-07-20 |
| https://firebase.google.com/docs/functions/quotas | 2026-07-20 |
| https://firebase.google.com/docs | 2026-07-20 |
| https://firebase.google.com/docs/cli/mcp-server | 2026-07-20 |
| https://firebase.google.com/pricing | 2026-07-20 |
| https://firebase.google.com | 2026-07-20 |
| https://appwrite.io/docs/apis/realtime | 2026-07-20 |
| https://appwrite.io/docs/products/functions | 2026-07-20 |
| https://appwrite.io/docs/products/storage | 2026-07-20 |
| https://appwrite.io/docs/products/auth | 2026-07-20 |
| https://appwrite.io/docs/advanced/self-hosting | 2026-07-20 |
| https://appwrite.io/docs/tooling/mcp | 2026-07-20 |
| https://appwrite.io/pricing | 2026-07-20 |
| https://appwrite.io | 2026-07-20 |
| https://pocketbase.io/docs/api-realtime/ | 2026-07-20 |
| https://pocketbase.io/docs/files-handling/ | 2026-07-20 |
| https://pocketbase.io/docs/authentication/ | 2026-07-20 |
| https://pocketbase.io/docs/going-to-production/ | 2026-07-20 |
| https://pocketbase.io/docs/go-migrations/ | 2026-07-20 |
| https://pocketbase.io | 2026-07-20 |
| https://www.instantdb.com/docs | 2026-07-20 |
| https://www.instantdb.com/docs/modeling-data | 2026-07-20 |
| https://www.instantdb.com/docs/storage | 2026-07-20 |
| https://www.instantdb.com/docs/auth | 2026-07-20 |
| https://www.instantdb.com/pricing | — |
| https://www.instantdb.com | 2026-07-20 |
| https://docs.nhost.io/products/database | 2026-07-20 |
| https://docs.nhost.io/products/storage | 2026-07-20 |
| https://docs.nhost.io/products/auth | 2026-07-20 |
| https://docs.nhost.io/platform/self-hosting | 2026-07-20 |
| https://nhost.io/pricing | — |
| https://nhost.io | 2026-07-20 |
| https://www.triplit.dev/docs | 2026-07-20 |
| https://www.triplit.dev/docs/schemas | 2026-07-20 |
| https://www.triplit.dev/docs/self-hosting | 2026-07-20 |
| https://www.triplit.dev | 2026-07-20 |
| https://zero.rocicorp.dev/docs | 2026-07-20 |
| https://zero.rocicorp.dev/docs/zero-schema | 2026-07-20 |
| https://zero.rocicorp.dev/docs/auth | 2026-07-20 |
| https://zero.rocicorp.dev/docs/deployment | 2026-07-20 |
| https://zero.rocicorp.dev | 2026-07-20 |
| https://electric-sql.com/docs/guides/shapes | 2026-07-20 |
| https://electric-sql.com/docs | 2026-07-20 |
| https://electric-sql.com/docs/guides/auth | 2026-07-20 |
| https://electric-sql.com/docs/guides/deployment | 2026-07-20 |
| https://electric-sql.com/pricing | — |
| https://electric-sql.com | 2026-07-20 |
| https://orm.drizzle.team/docs/overview | 2026-07-20 |
| https://neon.com/docs | 2026-07-20 |
| https://neon.com/docs/extensions/pgvector | 2026-07-20 |
| https://neon.com/docs/introduction/auto-suspend | 2026-07-20 |
| https://orm.drizzle.team/docs/kit-overview | 2026-07-20 |
| https://neon.com/docs/ai/neon-mcp-server | 2026-07-20 |
| https://neon.com/pricing | 2026-07-20 |
| https://neon.com/blog/neon-and-databricks | 2026-07-20 |
| https://neon.com | 2026-07-20 |

## Related comparisons

- [Database engines](https://toolweight.dev/compare/sqlite-vs-postgres-vs-mysql) — Should I use SQLite, PostgreSQL or MySQL?
- [Vercel alternatives](https://toolweight.dev/compare/vercel-alternatives) — Which Vercel alternative should I use, and what happens to my bill if my site goes viral?
- [S3-compatible storage](https://toolweight.dev/compare/s3-compatible-storage) — Which S3-compatible object storage provider is actually cheapest once egress is counted?
- [Coding agents](https://toolweight.dev/compare/coding-agents) — Which AI coding agent should I use in 2026?

## Licence and attribution

Data from toolweight (https://toolweight.dev), licensed CC-BY-4.0.

- Licence: [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)
- Canonical HTML: https://toolweight.dev/compare/convex-alternatives
- Machine-readable: https://toolweight.dev/compare/convex-alternatives.md · https://toolweight.dev/api/v1 · https://toolweight.dev/mcp
- toolweight takes no affiliate revenue and sells no placements. Corrections: https://toolweight.dev/suggest