migrate

bring your postgres to briven.

if your data is already in postgres, the move is pg_dump and pg_restore — the same two commands you would use between any two postgres hosts. briven's part is handing you an empty postgresql 18 database in seconds with pgvector already on, and then keeping it: nightly backups, restore points you name yourself, a branch you can make in half a second, and an undo. there is no wizard, no agent that reaches into your current platform, and no cutover button. you run the commands, so you decide when anything changes.

create a database ask a human first

the whole move, in four steps

01
create an empty database
one click in the dashboard. you get a real postgresql 18 database in seconds, with pgvector 0.8.6 already switched on — there is no extension to enable and no version to pick.
02
dump what you have
run this against your current database, from your machine. briven never touches your source: it does not have credentials for it and never asks for them. your existing setup keeps running, untouched, for as long as you like.
```
pg_dump --no-owner --no-privileges -Fc -d $OLD_URL -f dump.pgc
```
03
restore into briven
copy the connection string from the database page and restore into it. the connection goes through the pooler, which is the only thing briven exposes — so this is the same address your application will use afterwards.
```
pg_restore --no-owner --no-privileges -d $BRIVEN_URL dump.pgc
```
04
point your app at it
change one environment variable. anything that speaks postgres works unchanged. if you would rather not hold a connection at all, mint an api key and post sql to /api/v1/sql — it speaks neon's http protocol, so a stock @neondatabase/serverless client works without a single edit.

what does not come with you

briven is a postgres database with vector search, object storage, an http sql endpoint, branching, a row-by-row undo and a nightly backup. it is not a backend platform, and the list below is the part most migration pages leave for you to discover on the day you cut over.

your realtime subscriptions, as you wrote them. briven does push row changes to your application as they happen, but a supabase channel or a firestore listener is a different shape and the client half gets rewritten.
your end-user auth. briven's sign-in is for the briven dashboard, not for your application's users.
serverless or edge functions. there is no function runtime to deploy to.
your old backup arrangement — because briven has its own. a full backup every night, the write-ahead log archived continuously between them, and a restore that has actually been performed on the live server. the honest caveat: the backup repository currently sits on the same machine as the databases, so it will get you back from a dropped table or a bad migration, but not from losing that machine. off-site copies are being wired now. keeping your own periodic pg_dump somewhere else is still the sensible habit, and it is the habit you already have.
your past. branching, restore points and the row-by-row undo all work here, but the change log only starts recording the moment your data arrives — it can undo what you do on briven, not what you did before the move. (history is on starter and above; the free plan does not record it.)

coming from something that is not postgres?

firestore, mongodb, convex and dynamodb all export, but none of them export into a relational schema — somebody has to decide which nested fields become columns and which stay as jsonb. briven has no automated importer for any of them, and we are not going to imply otherwise. write to us with a paragraph about the shape of your data and we will tell you honestly whether it is a weekend or a quarter.

tell us about the move

no signup needed. the form fills in an email draft for you — you can read it and edit it before you send it.