briven· techsign up
menuclose
briven vs convex
plain postgres, and none of the reactivity.
convex is a reactive backend: you subscribe to a query and updates arrive, recomputed for you. briven does not do that, and this page is not going to pretend otherwise. what it does do is push row changes to your application as they happen — the smaller, plainer half — on top of a real postgresql 18 database handed to you in seconds, with pgvector already on, a pooler in front, sql over plain http, a branch you can make in half a second, an undo, and pg_dump as the door out. if the reactivity is what you are buying, buy convex.
feature
briven
convex
the database
everything else on this page follows from this one row.
a real postgresql 18 database. any postgres client connects to it, and pg_dump is the way out.
convex's own storage engine. you reach it through convex functions, not through a database client.
reactive queries
convex wins this outright, and it is the reason most people choose it.
not available. briven will tell you a row changed; it will not re-run your query and hand you the new result set.
first-class reactive queries — subscribe to a query and get pushed updates. this is the product.
realtime change delivery
the narrower half of the row above, and briven does have it.
changes pushed to your application as they happen, measured at 11 milliseconds from commit to delivery against a 200 millisecond budget.
folded into the reactive query model — you do not subscribe to changes, you subscribe to a query.
query language
sql. all of it, including joins, ctes, window functions and views.
typed convex query and mutation functions. no sql.
vector search
pgvector 0.8.6 already switched on when the database is created. you supply the embeddings.
vector search built into the platform, defined in your schema.
sql over http
post one statement to /api/v1/sql. it speaks neon's protocol, so a stock @neondatabase/serverless client works unmodified.
http actions call your convex functions. there is no sql endpoint, by design.
connection pooling
pgbouncer is the only thing you connect to. an idle database holds zero connections.
not something you think about — you never hold a database connection.
getting your data out
pg_dump and pg_restore. the standard postgres tools, unchanged.
convex's own export, in convex's own format.
machine access
api keys scopable to a single database and markable read-only, stored as a sha-256 hash.
deploy keys and convex auth integrations.
team controls
organisations, custom roles, a permission per resource and operation, and an audit log on pro and above.
teams, projects and member roles.
file storage
an s3-compatible bucket per database.
convex file storage, inside the same engine.
branching, history and undo
copy a database in well under a second and throw the copy away — 256 mb in 524 milliseconds, measured. and a change log row by row, with an undo that refuses rather than guessing when the row moved on since. starter and above for the history.
preview deployments give a branch of your code its own backend to run against.
backups
briven's backup repository is not held off-site yet.
a full backup every night plus continuous write-ahead-log archiving, and the restore has been performed on the live server rather than assumed. you can also name your own restore points.
managed snapshots and restore.
pricing
four flat plans — free, starter, pro, enterprise.
free tier, then usage-based metering on top of a monthly plan.
when convex wins
- you want reactive queries. that is convex's whole reason to exist and briven does not have them: briven pushes the change, it does not recompute your query.
- you want to write your backend as typed functions and never think about a connection, a pool or a migration.
- you want your snapshots held somewhere other than the machine running the database. briven backs up nightly and has proven the restore, but off-site copies are still being wired.
- you want the ecosystem — templates, hosted examples, and a community that has already solved your shape of problem.
when briven wins
- you want your data in real postgres, readable today by psql and every tool that has ever spoken to a postgres database.
- you need sql itself: joins, transactions, views, triggers, extensions, an explain plan you can read.
- you want the exit to be pg_dump — a format any host on earth can restore, not an export only one platform can read.
- you want vector search in the same database as your rows, with pgvector 0.8.6 already switched on.
- you want to keep writing @neondatabase/serverless and change only the host it points at.