DBML to SQL Converter

Paste a DBML schema and get back SQL CREATE TABLE DDL with foreign key constraints and indexes. Supports the full DBML syntax used by dbdiagram.io: Table blocks, column attributes ([pk, not null, unique, default: x, ref: > other.col]), standalone Ref declarations, and Indexes blocks. Choose PostgreSQL or MySQL for dialect-specific quoting and type handling.

How to use the DBML to SQL Converter

Paste your DBML into the input, select the target SQL dialect, and click Generate SQL. The output is a complete DDL script you can paste into a database client or save as a .sql migration file.

  1. Table blocks — each Table name { ... } becomes a CREATE TABLE statement. Column names and types are emitted as-is; DBML types match closely to SQL types (int, varchar, boolean, timestamp, text, etc.).
  2. Column attributes — [pk] → PRIMARY KEY, [increment] → AUTO_INCREMENT/SERIAL, [not null] → NOT NULL, [unique] → UNIQUE, [default: value] → DEFAULT value.
  3. References — both inline [ref: > other.col] and standalone Ref: a.col > b.col become FOREIGN KEY ... REFERENCES ALTER TABLE statements added after all CREATE TABLEs.
  4. Indexes — Indexes { (a, b) } blocks produce CREATE INDEX statements. A unique index is produced for Indexes { (a, b) [unique] }.

What is DBML and how does it relate to SQL DDL?

DBML (Database Markup Language) is a simple, human-readable DSL for defining relational database schemas. It was created by the team behind dbdiagram.io as a design-first alternative to writing SQL DDL — you describe your tables, columns, and relationships in a clean syntax and the tool renders a visual ER diagram. DBML is intentionally database-agnostic: it uses generic type names (int, varchar, boolean, timestamp) that map to each database engine's native types when you generate DDL.

The two primary operations with DBML are generating diagrams (for documentation and design review) and generating DDL (for execution). This converter handles the latter: it parses the DBML syntax and produces valid CREATE TABLE statements for PostgreSQL or MySQL. For PostgreSQL, increment becomes SERIAL and identifier quoting uses double quotes. For MySQL, increment becomes AUTO_INCREMENT and identifiers use backtick quoting. Foreign key relationships from Ref declarations are emitted as ALTER TABLE ... ADD CONSTRAINT FOREIGN KEY statements placed after all table definitions to avoid dependency order issues.

DBML is especially popular in teams that want to version-control their schema in a readable format alongside code, use dbdiagram.io for visual review during design, and then generate DDL for migrations. You can keep DBML as the source of truth and re-generate DDL after each schema change instead of hand-writing ALTER TABLE statements.

Common use cases

  • Design-to-DDL workflow — design your schema in dbdiagram.io, export the DBML, convert it to SQL DDL for your migration tool.
  • Multi-database deployments — maintain one DBML file and generate both PostgreSQL and MySQL DDL for different environments.
  • Schema documentation — keep DBML in your repo for readability, generate DDL on CI for deployment without duplicating definitions.
  • Onboarding new developers — DBML is easier to read than raw DDL; new team members review the DBML diagram and you generate the migration from it.
  • Migration baseline — when starting a new project with a designed schema, generate the initial migration from DBML instead of writing it by hand.

Frequently asked questions

Does it support all DBML relationship types (>, <, -)?
> means many-to-one (the left column references the right table — a standard FK), < means one-to-many (reverse), and - means one-to-one. All three are emitted as FOREIGN KEY constraints from the column that holds the FK value.

What happens to DBML enum types?
DBML enum blocks are not yet supported by this converter — the type is passed through as-is. For PostgreSQL, create the ENUM type separately before running the DDL. For MySQL, replace the type with ENUM('val1','val2') manually.

Are table notes and group blocks handled?
Notes (Note: "...") and TableGroup blocks are skipped — they are documentation-only features in DBML and have no SQL equivalent. The converter emits only structural DDL.

Can I use the output directly in production?
The output is valid DDL suitable for a migration file. Review the generated FOREIGN KEY constraints for correct ON DELETE/ON UPDATE behavior — DBML does not encode cascade rules, so the converter defaults to the database default (RESTRICT). Add ON DELETE CASCADE or SET NULL manually where needed.

What is the difference between [pk] and [pk, increment]?
[pk] alone emits PRIMARY KEY without auto-increment. [pk, increment] emits SERIAL PRIMARY KEY (PostgreSQL) or INT AUTO_INCREMENT PRIMARY KEY (MySQL). If you use a natural key (UUID, email) mark it [pk] only and omit [increment].