briven· techbeta v1migrate / drizzle
same postgres. same TS schema. plus reactivity, functions, hosting.
drizzle is a great query builder. briven is drizzle's shape + a hosted database + typed functions + reactive subscriptions + a deployment pipeline. you keep almost everything you already wrote.
what you're afraid of
is briven's schema DSL different from drizzle's?
minimally. both target postgres. column types map 1:1 (text, integer, boolean, timestamp, jsonb, etc.). drizzle's `pgTable()` becomes briven's `table()`. relations and indexes carry over.
do i lose my drizzle migrations?
no — we pg_dump your data from whatever postgres drizzle was pointing at. your existing schema lands intact. briven owns future migrations going forward.
will my db calls still be type-safe?
yes. briven's ctx.db is fully typed against your schema. inferred row types, inferred where-clause shapes, etc. — drizzle's big strength carries.
the conceptual mapping
your mental model survives the move. left column: what you call it in drizzle. right column: where it lives in briven.
| drizzle | briven |
|---|---|
| drizzle pgTable("notes", { ... }) | briven table({ ... }) — same column builders |
| drizzle relations | briven foreign keys + JOIN helpers |
| db.select().from(notes).where(eq(notes.id, x)) | ctx.db("notes").select().where({ id: x }) |
| your own pg-pool deployment | briven managed postgres + connection pooling |
| manual migration files | briven's schema diff → auto-generated migrations on deploy |
what the migration actually costs
ranked honestly: what comes for free, what we automate, what stays manual.
- free
data — your postgres becomes briven's postgres via pg_dump | pg_restore.
- auto
schema translation — drizzle schema.ts ports almost line-for-line to briven's DSL.
- manual
service-layer port — the code that calls drizzle becomes briven function files. one file per function. usually ~1 day for a medium app.
questions you actually have
- why move at all if i already have a working drizzle setup?
- three reasons: (1) hosted postgres + connection pooling without ops, (2) reactive subscriptions via useQuery, (3) zero-config function deployment. if you're happy running pg yourself, you don't need briven.
- can i keep drizzle alongside briven?
- briven's ctx.db has the same shape but isn't literally drizzle. you swap one for the other in the function layer. you can absolutely use drizzle on a separate database (e.g., analytics) and briven for your reactive app.
- what about drizzle studio?
- briven studio at /dashboard/projects/{id}/studio is the same idea — table viewer, query runner, schema editor.
ready to start? no signup needed
leave us your email and we'll reach out within one business day. your drizzle 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.