briven· techbeta v1migrate / firebase
firestore in your head, postgres on the floor.
firebase is nosql with realtime built-in. briven is real sql on postgres with realtime built-in. the hardest part of moving off firebase is the modelling — document → relational requires shape decisions per collection. we walk through them with you. we don't just dump.
what you're afraid of
do i have to redesign my data model?
some of it, yes — but we don't make you do it alone. briven samples your documents per collection and proposes a relational schema (flatten vs jsonb per field). you review every collection before we commit.
what about my realtime listeners?
they become briven useQuery() hooks. the callback-based snapshot model maps cleanly to react hooks; the wire model is different but the developer ergonomics are familiar.
do my users keep their accounts?
yes. firebase auth users (email/password + OAuth) port to Better Auth. we preserve provider+subject pairs so a "sign in with Google" user lands on their existing account, no fresh signup.
the conceptual mapping
your mental model survives the move. left column: what you call it in firebase / firestore. right column: where it lives in briven.
| firebase / firestore | briven |
|---|---|
| firestore collection | postgres table with shape decisions per field |
| embedded subdocument | jsonb column OR child table (your choice during review) |
| firestore document id | text column with ULID for new rows |
| firebase auth (Google/Apple/email) | Better Auth — providers reconfigure 1:1 |
| realtime onSnapshot listener | useQuery() — react hook, same wire-level guarantees |
| firebase storage | briven storage (S3-compatible, MinIO) |
| firebase functions (gen 2) | briven functions (Deno isolates) |
what the migration actually costs
ranked honestly: what comes for free, what we automate, what stays manual.
- auto
data export — firebase admin SDK dumps every collection. we stream it.
- auto
schema proposal — we sample your documents and propose a postgres schema. you review per collection before we commit.
- auto
auth — firebase auth users map to Better Auth, preserving provider+subject. existing OAuth users land on their account on first sign-in.
- manual
shape decisions — for each collection, you decide: flatten into columns? jsonb blob? hybrid? we propose, you approve.
- manual
cloud functions — port to briven functions; gen-2 Deno-style functions are close, but firebase-specific SDKs become postgres queries.
- manual
security rules → function guards — every rule becomes an explicit check inside the briven function that replaces the firestore access.
questions you actually have
- isn't document → relational just downgrading?
- no — briven supports jsonb columns, which give you document-store flexibility *inside* a relational schema. you can keep nested docs as opaque jsonb and only flatten the fields you query on. best of both.
- how long does a firebase migration take?
- longer than the others. we recommend a 2-week parallel-run window for non-trivial firebase apps because shape decisions surface over time. quoted as ~3-5 days of operator time.
- what about firebase's offline persistence?
- briven's client-side cache covers offline reads. offline writes require app-level queueing — same as firebase, just less invisible.
- will my flutter / unity / SwiftUI app work?
- briven has REST + WS endpoints that any client can hit. official SDKs are TS-only today; native clients ship over the next two quarters.
ready to start? no signup needed
leave us your email and we'll reach out within one business day. your firebase / firestore stays untouched the entire time.
already got a briven account?
jump straight into the in-product wizard for a more detailed intake form — you can save progress and track status from your dashboard.