real postgresql 18
not a lookalike, and not a layer sitting on top of one. a postgresql 18 database of your own, created in seconds, reachable from psql, prisma, drizzle or anything else that speaks postgres.
postgresql 18 · pgvector 0.8.6 · made in Flanders
a real postgres database.
ready in seconds.
postgresql 18 with pgvector already switched on, so searching by meaning works from your very first query — no extension to install and no second database to run. reach it over plain http, or with any postgres client you already own. branch it, rewind it, undo a change you regret. made in Flanders, independent.
ai search, nothing to install
pgvector 0.8.6 is already switched on. store embeddings beside your ordinary rows and search by meaning in the same query language as everything else — one database, not two.
idle costs nothing
every database sits behind a connection pooler, and one nobody is using holds no connections at all. a project you look at twice a month is not quietly burning anything in between.
independent, and staying that way
made in Flanders by flndrn, 100% self-funded. no investors to appease, no pivot-to-ads roadmap, no acquisition fire-sale waiting at the end of it.
two doors
over http, or with the postgres client you already use
both reach the same database. use whichever suits the thing you are building, and mix them freely.
sql over plain http
post one statement to /api/v1/sql with a bearer key and get rows back. we speak neon's own http protocol, so @neondatabase/serverless works against it unmodified — nothing to install, and no connection to hold open in a place that cannot hold one.
any postgres client
or take the connection string and point psql, prisma, drizzle or your orm of choice at the pooler. it is postgresql 18 underneath, so whatever already works with postgres already works here.
included
what comes with every database
the things an application needs on day two, already part of the platform rather than sold back to you as add-ons.
api keys, scoped
one key per program instead of one key for everything. tie a key to a single database, and mark it read-only when reading is all it ever needs to do.
object storage beside it
every database gets its own private s3-compatible bucket, so a file and the row pointing at it live in the same place and are deleted in the same breath.
organisations, roles, audit
build custom roles out of individual permissions rather than picking one of three fixed ones, and read back every action anybody took. an organisation is one account today — adding people to it is not built yet. custom roles and the audit trail arrive with the paid plans — the pricing table below says exactly which.
machine to machine
your software can use the database without a person in the room
a nightly job that tidies up yesterday's rows. a deploy step that checks a table before it lets the release through. your own application, serving somebody at four in the morning. none of them can open a browser or type a password — so they carry a key instead, post one statement over https, and get rows back.
bash
curl -sS https://briven.tech/api/v1/sql \
-H "Authorization: Bearer $BRIVEN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"query":"select id, title from notes where author = $1 limit 5","params":["ada"],"database":"notes"}'response
{
"command": "SELECT",
"rowCount": 2,
"rows": [
{ "id": 41, "title": "pooler notes" },
{ "id": 39, "title": "backup drill" }
],
"fields": [
{ "name": "id", "dataTypeID": 23, "format": "text" },
{ "name": "title", "dataTypeID": 25, "format": "text" }
]
}a key per program
issue a key, hand it to one program, and take it back the day that program retires. it reads brk_ followed by 43 random characters — 256 bits of them — and briven keeps only a hash, so the one time you see it is the time it is created. after that the last four characters are all anyone gets, which is enough to tell two keys apart and not enough to use one. free plans hold five keys, starter twenty, pro a hundred, and enterprise as many as you need.
tied down two ways
a key can be pinned to a single database, so a program that only ever touches one cannot reach the others. and it can be marked read-only, which is checked twice on the way in: the statement itself has to be a select or a with, and postgres is separately told the transaction may not write. those two switches are the whole scoping story — there is no permission list behind them, and briven would rather say so than imply one.
caps that do not bend
thirty seconds for a statement, ten thousand rows in a reply, four megabytes of request, a hundred parameters. they apply to every key on every plan and nobody can raise them. a request that crosses one is refused outright with a code your program can read — seventeen different refusals, each naming what was wrong — rather than truncated into an answer that looks right.
reading the shape of your account
a key that is not pinned to one database can also ask what exists: list your databases, fetch one, and list its branches, over the same bearer-token http. no key at all comes back 401 missing_api_key; a revoked or expired one comes back 401 invalid_api_key — the same answer for both, so nobody can sort guesses into wrong and merely retired.
what a key cannot do, so you know before you build rather than halfway through it: creating and deleting databases over the api is switched off for every organisation and there is no setting you can change — ask us and we will open it for your account. the command-line tool is real but unpublished, so there is nothing for you to install. there is no mcp server, so briven does not plug into claude, cursor or anything like them. there are no outbound webhooks. and realtime needs a browser session, which means a key can query but cannot subscribe.
shipped
your data has a history, and you can walk back through it
a database you can branch, rewind and undo. every one of these is running in production today, not sitting on a roadmap.
history and undo
every change is recorded row by row: who changed what, and when. undo one edit, a range of them, or a whole table. when a row has been changed again since, briven refuses rather than guessing — an undo that quietly overwrites somebody else's work is worse than no undo at all.
branching
take a copy of a database, break it, and throw it away. a 256 mb database was copied in 524 milliseconds — measured, not estimated — and the copy is independent from the moment it exists, so nothing you do to it can reach the original.
restore points
name a moment before you do something frightening, and go back to it. going back builds a fresh database beside the original rather than writing over it, so the thing you are recovering from cannot be made worse by the recovery. it refuses outright if the shape of your tables changed in between.
backups, with a tested restore
a full backup every night and the write-ahead log archived continuously between them. more to the point, the restore has actually been performed on the live server — a row written an hour after the backup, then deleted, was recovered. until a restore has been proven, a backup is only a hope.
realtime
changes pushed to your application as they happen, instead of your application asking again. from commit to delivery measured at 11 milliseconds against a 200 millisecond budget.
ai search, already on
pgvector is switched on from the first second, so storing embeddings beside ordinary rows and searching by meaning needs nothing installed. generating those embeddings for you is the one piece still coming — see below.
not yet
built, and waiting on the last switch
you should be able to find out what briven is not before you sign up, rather than afterwards.
this is not switched on for customers yet. the queue, the trigger and the worker are written and proven end to end, including text in and vector out — what has not happened is the model server running on production hardware.
automatic embeddings
write text, get a vector, without calling a model yourself. storing and searching vectors already works today and always has; having briven generate them for you is the part still to be switched on.
by design
three things briven does not do, and will not pretend to
ruled out on purpose rather than left off a roadmap. if your application needs one of these, briven is the wrong tool and you should know that before you sign up rather than after.
no autoscaling
a database gets the resources its plan gives it and no more. capacity that changes underneath you is capacity you cannot reason about, and a bill that changes with it is a bill you cannot predict.
no multi-region
one region. running the same data in several places means choosing which copy is right when they disagree, and briven would rather be a database you can explain than one that is quietly eventually consistent.
no read replicas
one primary, and every read sees what the last write wrote. a replica that is a few seconds behind is a whole class of bug that only appears in production.
not a big-tech company
briven is not built by a giant with a churn dashboard and a pivot-to-ads roadmap. it is made with ♥ in Flanders by flndrn — 100% self-funded, sustainable, and independent. no investors to appease, no rug-pulls, no acquisition fire-sale. just a tool we run ourselves, built to outlast the hype.
pricing
what each plan includes
the limits below are read straight out of the product's own plan rules, so what you see is exactly what the platform enforces. pay monthly or save two months by paying for the year.
pay monthly, or pay for 10 months and get the year — the same plan, two months cheaper. the limits beside each price are read straight out of the product's own plan rules, so what you see here is exactly what the platform enforces.
free
€0/month
included
- members
- 2
- roles
- —
- projects
- 1
- databases
- 1
- read replicas
- —
- api keys
- 5
- storage
- 100
- documents
- 50
- branches
- 1
- functions
- 3
- auth
- 3
- custom branding
- history
- audit log
starter
€19/month
or €190 a year · save €38included
- members
- 10
- roles
- 3
- projects
- 10
- databases
- 3
- read replicas
- —
- api keys
- 20
- storage
- 5,000
- documents
- 1,000
- branches
- 3
- functions
- 20
- auth
- unlimited
- custom branding
- history
- audit log
pro
€49/month
or €490 a year · save €98included
- members
- 50
- roles
- 20
- projects
- 100
- databases
- 20
- read replicas
- 1
- api keys
- 100
- storage
- 100,000
- documents
- 50,000
- branches
- 15
- functions
- 200
- auth
- unlimited
- custom branding
- history
- audit log
enterprise
€249/month
or €2490 a year · save €498included
- members
- unlimited
- roles
- unlimited
- projects
- unlimited
- databases
- unlimited
- read replicas
- 5
- api keys
- unlimited
- storage
- unlimited
- documents
- unlimited
- branches
- unlimited
- functions
- unlimited
- auth
- unlimited
- custom branding
- history
- audit log
every plan is a real postgresql 18 database with pgvector already switched on · api keys and object storage come with all of them · you can create an account today; card payments are not switched on yet. every figure above is a count of things, never gigabytes.