Skip to content
Postgres to DBML

A DBML export that follows your production schema.

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.

Live

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.

One click

From the ERD canvas

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.

Faithful

Tables, columns, keys, FKs

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.

Private

No rows in the DBML

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.

AI ready

Feed your coding agent the schema, not your DB

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.

Team-friendly

Commit it next to the code

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

What the DBML looks like.

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

You may not need the export at all.

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

Postgres to DBML converter: schema always in sync, no copy paste

Which PostgreSQL versions are supported? +

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.

Does the DBML file ever include row data? +

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.

How often is the DBML regenerated? +

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.

Can I paste the DBML straight into dbdiagram.io? +

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.

Is this the format my AI coding agent needs? +

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.

What happens with enums, JSON columns, and generated columns? +

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.

Ready to export

Get a DBML that always matches your live schema.

Install the agent, run a scan, click Export DBML. Under ten minutes from nothing to a file, and free for one connection.