briven· techsign up
menuclose
briven vs supabase
the same postgres. a different thing in front of it.
both briven and supabase run real postgres, so the argument is not about the database. supabase puts postgrest and row-level security in front of it and gives you client libraries. briven puts a connection pooler in front of it and gives you a connection string plus sql over plain http. supabase is the older and broader platform, and there are things below that it simply does and briven does not.
feature
briven
supabase
database
the one thing the two platforms genuinely agree on.
a real postgresql 18 database, created in seconds. standard wire protocol, any postgres client.
a real postgres database per project. standard wire protocol.
vector search
pgvector 0.8.6 is already switched on when the database is handed to you. nothing to enable.
pgvector is available; you enable the extension on the project.
how apps connect
the biggest architectural difference between the two.
a pooled postgres connection string, or sql over plain http. no client library is required.
postgrest's rest api and the supabase client libraries, or a direct postgres connection.
sql over http
post one statement to /api/v1/sql. it speaks neon's protocol, so a stock @neondatabase/serverless client works unmodified.
postgrest exposes tables and rpc over http; raw sql goes over the postgres wire protocol.
connection pooling
pgbouncer sits in front of every database and is the only thing you connect to. an idle database holds zero connections.
supavisor pools connections in front of every project.
authorization
organisations, custom roles, and a permission per resource and operation, checked on the server before anything runs.
row-level security policies in postgres, driven by jwt claims.
machine access
api keys you can scope to a single database and mark read-only. stored as a sha-256 hash, compared in constant time.
anon and service-role keys, narrowed by row-level security.
audit trail
every action in the organisation is written to an audit log you can read in the dashboard. available on pro and above.
postgres logs and project logs in the dashboard.
file storage
an s3-compatible bucket per database, on the same infrastructure as the database.
supabase storage, built on s3.
realtime
supabase is broader: briven delivers row changes and stops there.
changes pushed to your application as they happen. commit to delivery measured at 11 milliseconds against a 200 millisecond budget.
postgres changes, broadcast and presence — a mature part of the platform.
branching
different shapes: a briven branch is a copy you keep or bin.
copy a database and work in the copy. a 256 mb database was copied in 524 milliseconds, measured, and the copy is independent from the moment it exists. there is no merge back.
database branches for preview environments, on paid plans.
history and undo
a change log inside the database, row by row — who changed what and when. undo one change, a range, or a whole table, and it refuses rather than guessing when the row has been changed again since. starter and above.
nothing per-row built in: you restore a backup, or write your own audit triggers.
restore points
name a moment before you do something frightening and go back to it. going back builds a new database beside the original, and refuses outright if the shape of your tables changed in between.
point-in-time recovery on paid plans, restoring the project itself.
backups
supabase wins the off-site copy and the self-service restore.
a full backup every night plus the write-ahead log archived continuously between them — and the restore has actually been performed on the live server. the backup repository still sits on the same machine as the databases.
managed backups, with point-in-time recovery on paid plans.
auth for your end users
supabase wins this outright.
not available. briven auth signs you in to the briven dashboard; it is not an auth product for your app.
supabase auth: a full end-user identity product with providers, sso and mfa.
pricing
four flat plans — free, starter, pro, enterprise.
free tier, then a monthly plan plus metered compute add-ons.
when supabase wins
- you need broadcast or presence, or the client libraries that carry them. briven delivers row changes and nothing beyond that.
- you need your backups held somewhere other than the machine running the databases, or a restore you can trigger yourself. briven backs up nightly and has proven the restore, but the repository is not off-site yet and a human runs the recovery.
- you need row-level security: policy in the database, enforced against a client that connects directly. briven checks permissions on the server instead, which is a different model and not a substitute.
- you need auth for your own end users — providers, sso, mfa. briven's sign-in is for the briven dashboard only.
- you want postgrest specifically: the generated openapi spec, the query builder in the client, pg_graphql.
- you already run on supabase and it works. moving a working system costs more than most comparison tables admit.
when briven wins
- you want a database in seconds with pgvector 0.8.6 already on, rather than a project to configure.
- you want to talk sql, not a client library. the pooled connection string and /api/v1/sql are the whole api surface.
- you already write against @neondatabase/serverless and want it to keep working, unmodified, against a different host.
- you want api keys narrowed to one database and marked read-only, instead of one wide key held back by policies.
- you want organisations, custom roles and an audit trail as part of the platform rather than as something you build.
- you want to copy a database in half a second, break the copy and bin it — and undo a bad write row by row on the days you did not think to copy it first.