briven· techbeta v1migrate / mongodb
document flexibility, postgres durability.
mongodb gave you schema flexibility; briven's jsonb columns + postgres tables give you the same thing without the operational surface of a separate database. and you get convex-style reactivity for free on top.
what you're afraid of
do i have to flatten every nested document?
no — fields you don't query on stay as jsonb. the rule we apply: if you ever filter or sort on a field, flatten it into a column. otherwise leave it in jsonb. you review per collection.
what about ObjectId, my embedded refs, $lookup pipelines?
ObjectIds become text columns with ULIDs for new rows. embedded refs become foreign keys. $lookup pipelines become postgres joins, which are faster.
can i still use aggregation-style queries?
yes — postgres has window functions, CTEs, and json operators. anything mongo aggregation does, postgres does too. usually faster.
the conceptual mapping
your mental model survives the move. left column: what you call it in mongodb. right column: where it lives in briven.
| mongodb | briven |
|---|---|
| collection | table (with jsonb columns where appropriate) |
| ObjectId | text + ULID for new rows; preserved for existing rows |
| embedded document | jsonb column OR child table (decide per field) |
| $lookup aggregation | JOIN in a briven function (faster, indexable) |
| mongoose schema validation | zod validation inside the briven function |
| change streams | useQuery() reactivity on touched tables |
what the migration actually costs
ranked honestly: what comes for free, what we automate, what stays manual.
- auto
data export — mongoexport per collection, streamed.
- auto
schema proposal — we sample documents and propose a relational schema. you decide per field: flatten or jsonb.
- manual
shape decisions — same as firebase. document-store data needs human review to land well in postgres.
- manual
application-side queries — mongoose / native driver calls become ctx.db chains. mechanical but tedious.
questions you actually have
- won't i lose flexibility?
- only where it was hurting you. jsonb columns preserve schemaless storage for the fields where flexibility helped; flattened columns add indexes + foreign keys where you wanted them.
- what about atlas vector search?
- briven has pgvector enabled by default. vector search works on the same postgres; you don't need a separate vector store.
- how does the move compare to migrating to documentdb / cosmos?
- simpler. those are still document stores with mongo-compatible APIs; briven is a fundamentally different data model. but the migration is more thoughtful — you exit nosql, you don't just sideways-port.
ready to start? no signup needed
leave us your email and we'll reach out within one business day. your mongodb 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.