Generated from the last scan
Not from a DBML file you edit by hand. The agent scans your Postgres, Taavik emits the DBML from the metadata catalogue. Every migration lands in your DBML the next scan cycle.
Most DBML files rot the day after they are exported. Taavik regenerates the DBML from the last agent scan, every time you click Download. Your dbdiagram.io board, your dbdocs.io site, your AI coding agent context: always the current shape of the database, never a snapshot from three months ago.
Not from a DBML file you edit by hand. The agent scans your Postgres, Taavik emits the DBML from the metadata catalogue. Every migration lands in your DBML the next scan cycle.
Open the schema map, click Export, pick DBML, and the browser downloads it. Drop the file into dbdiagram.io or into a coding agent without pasting anything or massaging the format first.
Types keep their lengths, so varchar(255) stays varchar(255). Primary keys, unique constraints and nullability come across, cross-schema foreign keys arrive as Ref statements, and table comments land as Notes.
The on-premise agent sends the catalog, and the DBML is built from it. Not one row of your tables ends up in the file. What the cloud holds beyond the catalog is set out on the security page.
DBML is the format Claude, Cursor, and Windsurf parse best. Ship the file instead of pointing the agent at a database connection. Or skip the file: your assistant can read the catalog by itself.
Regenerate on release, review the diff in PR, get schema drift visible in the same review flow as your code. Or wire it in CI: fetch the DBML, diff, fail on unexpected change.
Example output
A DBML file emitted by Taavik for a public.orders / public.users pair. Table shape, column types, foreign keys, all resolved from the live scan.
// Auto-generated by Taavik.
// Regenerated on every schema scan: do not edit by hand.
Table public.users {
id uuid [pk]
email varchar(255) [not null, unique]
created_at timestamptz [not null]
}
Table public.orders {
id uuid [pk]
user_id uuid [not null, ref: > public.users.id]
status varchar(32) [not null]
total_cents bigint [not null]
created_at timestamptz [not null]
}
Ref: public.orders.user_id > public.users.id
If the file is for an assistant
Exporting DBML for an AI assistant works, until the schema moves and the file in the conversation is a week old. Taavik can hand the assistant the catalog directly instead: it looks up tables and columns by itself, reads the relations your database never declared, and sees which values a column really holds. No file to regenerate, no credentials to share.
FAQ
The on-premise agent supports PostgreSQL 12 and later, including managed variants such as Amazon RDS, Aurora, Azure Database for PostgreSQL, and Google Cloud SQL. Cross-schema foreign keys resolve correctly across all of them.
No. The agent extracts schema metadata only, and the DBML emitter reads from that metadata. Column types, constraints, and comments cross the wire; no row of your data ever does.
Every time you click Export. Under the hood, Taavik reads the last scan snapshot, so the DBML always matches the schema as of the most recent agent run. Trigger a new scan first if you just shipped a migration.
Yes. The output validates cleanly against the dbdiagram.io parser. Cross-schema foreign keys use explicit Ref statements outside the table blocks so the parser accepts them without errors.
DBML is one of the most parseable schema formats for large language models. Claude, Cursor, Windsurf, and Copilot all handle it well as tool context. Feed the DBML to the agent instead of exposing the database connection.
Enum types map to varchar with the enum labels in a table Note. JSON and JSONB columns keep their native types. Generated columns are marked with a Note tag so the target tool knows they are not directly writable.
Install the agent, run a scan, click Export DBML. Under ten minutes from nothing to a file, and free for one connection.