briven· techbeta v1briven vs supabase
typed functions + reactive queries on the same postgres.
both briven and supabase run on real postgres. the architectural split is at the api layer: supabase exposes the database via postgrest with row-level security, briven puts a typed function layer in front and adds query-level reactive subscriptions that supabase doesn't have.
feature
briven
supabase
database
postgres 17 + pgvector. one schema per project.
postgres 15/16 + pgvector. one schema per project.
data access
biggest architectural difference between the two.
typed query/mutation functions. the client only calls function names.
postgrest exposes tables directly; the client constructs queries.
authorization
server-side function logic with project-scoped connections.
row-level security policies in postgres + jwt claims.
reactive queries
listen/notify-based reactive subscriptions, deduped + cached server-side.
realtime via wal replication; subscribe-to-changes, not subscribe-to-queries.
schema migrations
`briven deploy` diffs schema.ts against live db, applies transactionally.
sql migration files via supabase cli or your tool of choice.
auth
better-auth with magic link, oauth (google/github/discord), email+password.
gotrue with the same providers + sso + mfa.
file storage
minio bundled (s3-compatible). point at your own s3/r2 self-hosted.
supabase storage built on s3.
edge functions
deno runtime per project, warm-cached. one isolate per project.
supabase edge functions via deno deploy.
self-host
agpl-3.0 core, single compose file, runs anywhere docker runs.
apache 2.0, supabase self-host stack is ~12 containers but well-documented.
pricing
€0 free, €29 pro, €99 team. flat fees, no compute surprises.
$0 free, $25 pro + usage. compute add-ons billed separately.
when supabase wins
- ·you want postgrest's rest api directly — generated openapi spec, query builder in the client, etc.
- ·you have a large supabase migration already and the cost of moving outweighs the gains.
- ·you need first-class row-level security as your security boundary (briven uses functions instead).
- ·you want supabase's pgrest tooling: pg_graphql, pg_hooks, native postgrest features.
when briven wins
- ·you want typed function calls instead of building queries on the client.
- ·you want convex-style reactive queries (subscribe to a query, get pushed updates when underlying tables change).
- ·you want a one-command export of your entire project (pg_dump + functions + env), portable to any host.
- ·you want a simpler self-host story — one compose file, three containers in the minimal mode.