briven vs firebase
when you outgrow nosql, briven is real sql with the same realtime ergonomics.
firebase shines at mobile prototypes and document-shaped data. once your data picks up relations, transactions, and predictable scale, briven is the postgres-shaped version of the same idea — typed queries, reactive subscriptions, server-side authz, and a bill you can predict.
feature
briven
firebase
data model
the fundamental shape of your data lives here.
relational. tables, columns, foreign keys, transactions.
document. collections of json-like documents with nested subcollections.
query language
sql, plus typed query functions. joins are free.
firestore queries; joins require fan-out reads or denormalisation.
transactions
postgres acid transactions. multi-table, multi-row, fully isolated.
firestore transactions limited to a small set of documents.
reactive queries
subscribe to a typed query; get pushed updates on any underlying-table change.
snapshot listeners on document/collection paths.
security
server-side typed functions with project-scoped db connections.
security rules evaluated on every request; runs on client query.
export
pg_dump. one command, the whole project.
firestore export to gcs. binary format, not directly importable elsewhere.
self-host
agpl-3.0. runs anywhere docker runs.
no self-host. google cloud only.
auth
better-auth with magic link, oauth, email+password — bundled.
firebase auth with broad oauth + phone auth + anonymous accounts.
file storage
minio (s3-compatible) bundled.
cloud storage for firebase (gcs underneath).
pricing
€0 free, €29 pro, €99 team. flat fees, predictable.
pay-as-you-go: per read, per write, per delete, per gb. famously hard to predict.
when firebase wins
- ·you're building a quick mobile prototype and want phone-number auth + offline-first sync out of the box.
- ·your data is genuinely document-shaped (nested, schemaless, varying per record).
- ·you're already on google cloud and want everything in one billing line.
when briven wins
- ·you outgrew nosql and want joins, transactions, and a proper relational model.
- ·you want predictable monthly pricing instead of per-operation billing.
- ·you want your data in a format you can move anywhere (pg_dump → any postgres host).
- ·you want server-side authz logic in typescript, not security-rule dsl evaluated on each query.
- ·you need eu data residency or your own hardware.