What do >, <, - mean in refs?

They indicate **relationship sides**. ` ` = many-to-one, `-` = one-to-one. Example: `Ref: posts.user_id > users.id` means "one user has many posts", and the foreign key lives in the `posts` table. The converter understands these directions and emits the FK on the correct side.

Does it generate foreign keys with ON DELETE CASCADE?

Only **plain FOREIGN KEY** without ON DELETE/UPDATE rules. DBML supports `[delete: cascade]` on a ref, but tool support is inconsistent. The output gets bare `REFERENCES table(column)`. Add `ON DELETE CASCADE` by hand where you need it. This is one of the spots where the converter deliberately does not guess, to avoid introducing a bug in production.

Why does MySQL output use backticks and PostgreSQL use double quotes?

Each engine uses a different identifier-quoting convention. **MySQL**: ``backticks``. **PostgreSQL and SQLite**: `"double quotes"`. **MSSQL** (not supported here): `[square brackets]`. The converter picks the right style so the output works as-is.

How does it convert "integer [increment]"?

Depends on the dialect. **PostgreSQL**: `SERIAL` (or `BIGSERIAL` for bigint). **MySQL**: `INT AUTO_INCREMENT`. **SQLite**: `INTEGER` (which auto-increments by default with `PRIMARY KEY`). These are the classic translations. If you prefer the newer `GENERATED ALWAYS AS IDENTITY` in Postgres, tweak the output after generation.

Can I use a schema (Table schema.users)?

Yes, the parser recognizes a schema prefix in table names. `Table public.users { ... }` produces `CREATE TABLE "public"."users" ( ... )`. **MySQL** does not have schemas in the classic sense (it uses "database" instead), but the output is syntactically valid.

**PostgreSQL** gets a native `CREATE TYPE ... AS ENUM (...)`. **MySQL and SQLite** get a **comment** with the allowed values, because the idiomatic implementation in those databases is `ENUM(...)` on the column (MySQL) or `TEXT CHECK (col IN ...)` (SQLite), which requires knowing **which column** uses the enum, and our minimal parser does not bind that automatically.

Why does the output not look exactly like dbdiagram.io export?

dbdiagram.io generates SQL with extra options and sometimes extra sections (comments, ALTER TABLE for FKs separately). Our converter is minimalist: CREATE TABLE + CREATE INDEX + ALTER TABLE for out-of-block refs, no decoration. The output is **syntactically compatible**, though the layout may differ.

What if I have a parse error in DBML?

The converter **still tries to generate SQL** for what it understands, and the **error list** appears below with line numbers. Most common errors: unclosed `[` bracket, typo in a type, unclosed `{` block, malformed ref syntax. Fix them and the error list should clear.

Does my data go to any server?

No. The whole parser and SQL emitter runs in your browser in JavaScript. DBML never leaves your machine.

DBML to SQL Converter - free

Dialect

Format result

DBML (input)3 tables / 3 refs

SQL (output)

CREATE TYPE "post_status" AS ENUM('draft', 'published', 'archived');

CREATE TABLE "users" (
  "id" SERIAL PRIMARY KEY,
  "email" VARCHAR(255) NOT NULL UNIQUE,
  "name" VARCHAR(100) NOT NULL,
  "is_active" BOOLEAN NOT NULL DEFAULT TRUE,
  "created_at" TIMESTAMP NOT NULL DEFAULT now()
);

CREATE TABLE "posts" (
  "id" SERIAL PRIMARY KEY,
  "user_id" INTEGER NOT NULL,
  "title" VARCHAR(200) NOT NULL,
  "body" TEXT,
  "published_at" TIMESTAMP,
  FOREIGN KEY ("user_id") REFERENCES "users" ("id")
);

CREATE TABLE "comments" (
  "id" SERIAL PRIMARY KEY,
  "post_id" INTEGER NOT NULL,
  "user_id" INTEGER NOT NULL,
  "body" TEXT NOT NULL,
  "created_at" TIMESTAMP NOT NULL DEFAULT now(),
  FOREIGN KEY ("post_id") REFERENCES "posts" ("id"),
  FOREIGN KEY ("user_id") REFERENCES "users" ("id")
);

CREATE UNIQUE INDEX "users_email_idx" ON "users" ("email");

CREATE INDEX "posts_user_id_published_at_idx" ON "posts" ("user_id", "published_at");

What is DBML and why convert it to SQL?

DBML (Database Markup Language) is a format from Holistics, used in the popular dbdiagram.io tool. It lets you describe a database schema in a clean, compact form, without the full SQL syntactic ceremony.

In DBML you write `Table users { id integer [pk] name varchar }` instead of `CREATE TABLE users (id INTEGER PRIMARY KEY, name VARCHAR(255))`. Shorter, more readable, easier to review. But eventually you need real SQL to create tables in a real database.

This tool converts DBML to SQL for PostgreSQL, MySQL, or SQLite. Supports: tables, columns with types, primary keys, auto-increment, NOT NULL, UNIQUE, defaults, indexes, foreign keys (Refs), enums. Also shows parse errors with line numbers.

How to use it

Paste your DBML schema into the left panel. The format follows dbdiagram.io.

Pick the target dialect: PostgreSQL, MySQL, or SQLite. Each has its own types and conventions.

On the right you get CREATE TABLE and ALTER TABLE ready to paste into a migration or your database.

If there are parse errors, the list appears below with line numbers. Fix the input and the output updates.

Copy the result with the Copy button and paste into your migration tool, Prisma, Drizzle, Flyway, Liquibase, whatever you use.

The Format result toggle runs the output through a SQL formatter for clean indentation. Disable it for raw output.

When this is useful

Common scenarios:

Designing a new database from scratch. You start in DBML because it is faster to capture ideas than full SQL. Once the schema settles, you generate CREATE TABLE.
Syncing a diagram with a migration. You have a diagram in dbdiagram.io (or exported from another tool) and want to create tables in a new database. The converter shortens that path.
Technical documentation. DBML is readable for non-engineers. SQL is executable. Write once in DBML, generate SQL for developers and a diagram for the product manager.
Schema code review before a migration. Easier to spot a mistake in DBML than in many CREATE TABLE lines.
Learning SQL. Watch how a simple `Table users { id integer [pk] }` expands into full `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)`. A nice learning path.

After generating SQL, you may want to format it. Need an ORM schema instead? See the SQL to ORM converter.

Questions and answers

Tables with any number of columns, types (integer, varchar(255), text, boolean, timestamp, etc.), column settings in square brackets: `pk`, `primary key`, `increment`, `not null`, `null`, `unique`, `default: ...`, `note: ...`, `ref: > table.column`. Indexes blocks: single and multi-column indexes, `unique` and `name` options. Refs outside tables: `Ref: a.col > b.col`, `<`, `-`. Enum with a list of values. Comments `// line`. Schema in table names like `public.users`.

CREATE TYPE "post_status" AS ENUM('draft', 'published', 'archived'); CREATE TABLE "users" ( "id" SERIAL PRIMARY KEY, "email" VARCHAR(255) NOT NULL UNIQUE, "name" VARCHAR(100) NOT NULL, "is_active" BOOLEAN NOT NULL DEFAULT TRUE, "created_at" TIMESTAMP NOT NULL DEFAULT now() ); CREATE TABLE "posts" ( "id" SERIAL PRIMARY KEY, "user_id" INTEGER NOT NULL, "title" VARCHAR(200) NOT NULL, "body" TEXT, "published_at" TIMESTAMP, FOREIGN KEY ("user_id") REFERENCES "users" ("id") ); CREATE TABLE "comments" ( "id" SERIAL PRIMARY KEY, "post_id" INTEGER NOT NULL, "user_id" INTEGER NOT NULL, "body" TEXT NOT NULL, "created_at" TIMESTAMP NOT NULL DEFAULT now(), FOREIGN KEY ("post_id") REFERENCES "posts" ("id"), FOREIGN KEY ("user_id") REFERENCES "users" ("id") ); CREATE UNIQUE INDEX "users_email_idx" ON "users" ("email"); CREATE INDEX "posts_user_id_published_at_idx" ON "posts" ("user_id", "published_at");

What is DBML and why convert it to SQL?

How to use it

Paste your DBML schema into the left panel. The format follows dbdiagram.io.

Pick the target dialect: PostgreSQL, MySQL, or SQLite. Each has its own types and conventions.

On the right you get CREATE TABLE and ALTER TABLE ready to paste into a migration or your database.

If there are parse errors, the list appears below with line numbers. Fix the input and the output updates.

Copy the result with the Copy button and paste into your migration tool, Prisma, Drizzle, Flyway, Liquibase, whatever you use.

The Format result toggle runs the output through a SQL formatter for clean indentation. Disable it for raw output.

When this is useful

Common scenarios:

Designing a new database from scratch. You start in DBML because it is faster to capture ideas than full SQL. Once the schema settles, you generate CREATE TABLE.
Syncing a diagram with a migration. You have a diagram in dbdiagram.io (or exported from another tool) and want to create tables in a new database. The converter shortens that path.
Technical documentation. DBML is readable for non-engineers. SQL is executable. Write once in DBML, generate SQL for developers and a diagram for the product manager.
Schema code review before a migration. Easier to spot a mistake in DBML than in many CREATE TABLE lines.
Learning SQL. Watch how a simple `Table users { id integer [pk] }` expands into full `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)`. A nice learning path.

After generating SQL, you may want to format it. Need an ORM schema instead? See the SQL to ORM converter.

Questions and answers

DBML to SQL Converter

What is DBML and why convert it to SQL?

How to use it

When this is useful

Questions and answers

Related tools

SQL Formatter

SQL Dialect Converter

SQL to ORM Converter

Database Connection String Parser

DBML to SQL Converter

What is DBML and why convert it to SQL?

How to use it

When this is useful

Questions and answers

Related tools

SQL Formatter

SQL Dialect Converter

SQL to ORM Converter

Database Connection String Parser