briven· techsign up
menuclose
briven vs firebase
when the documents grow relations.
firebase is very good at the first six months: realtime listeners, offline sync, auth in an afternoon. briven pushes changes as they happen too, but it has no offline sync and no auth product for your own users. what briven is for is the part after — when the data has picked up relations, the fan-out reads have become the slow part, and the bill has become a count of operations nobody can forecast. relational postgres 18, joins, transactions, a branch you can make in half a second, an undo, and four flat plans.
feature
briven
firebase
data model
the shape of your data lives in this row, and it decides most of the rest.
relational. tables, columns, foreign keys, constraints, transactions.
document. collections of json-like documents with nested subcollections.
query language
sql. joins cost you a keyword.
the firestore query api. joins are fan-out reads or denormalised copies you maintain.
transactions
postgres acid transactions across as many tables and rows as you like.
transactions, bounded by firestore's document limits.
vector search
pgvector 0.8.6 already switched on when the database is created, in the same database as your rows.
firestore vector indexes, configured per collection.
how apps connect
a pooled postgres connection string, or one statement posted to /api/v1/sql over plain http.
the firebase sdks, or the firestore rest api.
sql over http
yes — /api/v1/sql speaks neon's protocol, so a stock @neondatabase/serverless client works unmodified.
no sql surface. queries go through firestore's api.
realtime
firebase wins the offline half, which is the half a mobile app needs.
changes pushed to your application as they happen — 11 milliseconds from commit to delivery, measured against a 200 millisecond budget. no offline sync, and no recomputed query results.
snapshot listeners and offline sync — mature, and the reason most people choose firebase.
auth for your end users
firebase wins this outright.
not available. briven auth signs you in to the briven dashboard, not into your app.
firebase auth: broad oauth, phone auth, anonymous accounts, all bundled.
authorization
organisations, custom roles and a permission per resource and operation, checked on the server. api keys can be scoped to one database and marked read-only.
security rules, evaluated against every client query.
file storage
an s3-compatible bucket per database.
cloud storage for firebase, on google cloud storage underneath.
getting your data out
pg_dump. any postgres on earth can restore it.
firestore export to cloud storage, in google's own format.
branching, history and undo
copy a database in half a second and bin the copy when you are done — 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.
a second firebase project is the usual way to get a second environment.
backups
firebase wins the off-site copy.
a full backup every night plus the write-ahead log archived continuously, and the restore has been performed on the live server rather than assumed. you can also name your own restore points. the repository is not off-site yet.
scheduled backups and point-in-time recovery.
pricing
four flat plans — free, starter, pro, enterprise.
pay per read, per write, per delete, per gb. famously hard to predict before you ship.
when firebase wins
- you are building a mobile app and want offline sync on day one. briven pushes changes as they happen, but it has nothing for a client that has been off the network and needs catching up.
- you want phone-number auth, anonymous accounts and social login without building an identity layer.
- your data really is document-shaped — nested, schemaless, and different from one record to the next.
- you want your backups held somewhere other than the machine running the database. briven takes them nightly and has proven the restore; off-site copies are being wired now.
- you are already on google cloud and want one bill and one console.
when briven wins
- you have outgrown nosql and want joins, foreign keys and real transactions instead of denormalised copies you maintain by hand.
- you want a bill you can predict before you ship, rather than a price per read that scales with your worst day.
- you want vector search sitting in the same database as the rows it describes, with no separate index service.
- you want your data in a format you can move anywhere — pg_dump into any postgres host, including your own laptop.
- you want a database in seconds and a connection string, with no console, no sdk and no rules language to learn.