A real Postgres database with a thin layer that makes it friendly: one file for tables and rules,
every write checked by those rules, every read filtered by the same rules and live when you subscribe,
and a trace of every interaction that shows who called, which rule decided, what changed and who was told.
An agent can set it up through MCP without footguns because the rules are checked and the trace tells it what went wrong.
Leaving means deleting the layer and keeping the database. Many people first meet it through WordPress, but it is a database for any app.
The landscape
Each of these is good at something. Each leaves a gap: friendly from the first minute, Postgres as the real database, and a clear record of what happened.
Product
Query model
Where the data lives
The complaint
Firebase
NoSQL + rules, or GraphQL over Cloud SQL
Google
Two models; the exit is an export
Supabase
SQL + RLS
Your Postgres
RLS and realtime setup are where the complexity lives
Convex
TypeScript functions
Convex format, Postgres as storage
Friendly, but the data is not plain tables
Electric / PowerSync / Zero
SQL on a local replica
Your Postgres
"Friendly on top, Postgres underneath", for developers only
dabadata
Declared tables, rules that read like membership, plain SQL underneath
Your Postgres, plain tables
Young: no offline or mobile SDK yet
One by one
What each product is, where people get stuck with it, and what we do instead.
Firebase
The default for a first mobile app.
What it is
Firestore and the Realtime Database (NoSQL with a security rules language), plus SQL Connect: Cloud SQL Postgres behind a GraphQL schema with generated SDKs. Google distribution, auth, push and hosting in one console.
Where it hurts
Two data models in one product. Rules are a separate language that is easy to get wrong and hard to test. SQL Connect needs a schema and connectors before the first row. Debugging spans several consoles, and the exit is an export from Google.
Our answer
Plain tables and plain SQL, with the rules in one file next to the schema. Instead of a bare permission error, the trace shows which rule decided each request and why.
Supabase
Real Postgres, a large community and good docs.
What it is
Hosted Postgres with auth, storage, edge functions, realtime and a good studio. Open source and self-hostable. It already won the Postgres-versus-Firebase argument for developers.
Where it hurts
Security is Row Level Security written as SQL policies, and after a handful of them the results get hard to trace. Realtime filtered by RLS can behave differently from queries, and there is no way to see why a client did or did not receive a change.
Our answer
No RLS to write. Rules read like membership, and reads and live updates are filtered by the same rules, so a query and its subscription agree. The simulator says whether user X can see row Y and which rule decided.
Convex
The friendliest developer experience of the group.
What it is
A reactive backend where schema and queries are TypeScript functions, every query is a live subscription and transactions are automatic. Open source, self-hostable on SQLite, Postgres or MySQL.
Where it hurts
Postgres is storage for Convex's own tables, not a schema you query with SQL or point other tools at. Growing out of it is a migration either way, and the logs show function calls, not why a client got or missed an update.
Our answer
Keep the simplicity - one file, every subscription live - on real Postgres tables that any SQL tool, BI dashboard or ORM can read. Leaving means turning off our layer and keeping the database as it is.
Electric, PowerSync, Zero and the sync-layer vendors
Closest to us technically.
What it is
Sync engines that put a subset of your Postgres on the client and keep it live, with years of work on partial replication, conflicts and offline.
Where it hurts
Built for developers who already have a backend. Each has its own permission or shape language, there is no agent surface, and debugging a client that is missing rows is as hard as anywhere else.
Our answer
We do not compete on sync engine depth. We compete on the layer above it: rules that read like membership, the trace, the MCP surface, and site owners as a first market.
Same app, elsewhere
Estimates, October 2026 list prices, same usage model.
Convex Pro~$540
Firestore~$180
Supabase Pro~$140
dabadata~$49
Monthly bill for the same app: 1,500 concurrent connections, 15,000 daily users. Estimates, October 2026 list prices.
Project size
Firestore
Supabase Pro
Convex Pro
dabadata
100 concurrent, 1k daily users
~$10
$25
$25-30
$9(Starter)
1,500 concurrent, 15k daily
~$180
~$140
~$540
~$49($29 + $5 for 1,000 extra connections + ~$15 egress)
5,000 concurrent, 50k daily
~$600
~$550
~$1,800
~$139($99 + $10 for 2,000 extra connections + ~$30 egress)
No mobile SDK, offline or partial replication yet. Firebase and the sync vendors win any app that needs offline on day one.
No server functions or push notifications yet. File storage, static sites and hosted sign-in for your users (email and password, Google, Apple, Microsoft, GitHub and more) are built in, and your own identity provider's tokens work as they are. Server-side functions are coming; push notifications, phone sign-in and multi-factor are not built.
Trust and track record. All four have years in production. Our answer is an open core and the trace, which makes failures visible instead of mysterious.
A small team. Scope discipline is the whole strategy.
See it move
Two people, one live database, and a trace that explains every decision.