DBML → SQL (Export) | ERD Generator Docs

Once your schema is defined in DBML, exporting it back to SQL allows you to turn visual design into executable database scripts.
The DBML → SQL export bridges the gap between architecture and implementation — helping you move faster from design to production.

This guide walks you through:

• Exporting DBML to SQL
• Choosing the correct SQL dialect
• Previewing and validating generated SQL
• Best practices for safe usage in real environments

📌 Why Export DBML to SQL?

DBML is ideal for designing and visualizing schemas, while SQL is required for execution in real databases.

Exporting to SQL helps you:

• Bootstrap new databases
• Share schema definitions with backend teams
• Review migrations before execution
• Maintain consistency across environments

DBML remains the source of truth, while SQL becomes the deployable artifact.

🚀 How DBML → SQL Export Works

Step 1 — Open the DBML → SQL Export

In the editor toolbar, click the DBML → SQL CTA.

This opens the export panel where SQL is generated instantly from your current DBML schema.

Step 2 — Choose SQL Dialect

Select the target database dialect before exporting.

Supported output formats:

• MySQL
• PostgreSQL
• PostgreSQL (Legacy)
• Microsoft SQL Server
• Microsoft SQL Server (Legacy)

Each dialect adapts:

• Data types
• Auto-increment strategies
• Constraint syntax
• Index and key definitions

Choosing the correct dialect ensures the SQL runs without modification.

Step 3 — Preview Generated SQL

Before copying or exporting:

• Review the generated CREATE TABLE statements
• Validate primary keys, foreign keys, and indexes
• Confirm default values and constraints

The preview allows you to verify intent before execution, reducing migration errors.

Step 4 — Copy or Export SQL

Once validated, you can:

• Copy SQL directly to clipboard
• Paste into migration files
• Run in local or production database environments

The exported SQL is clean, readable, and structured for real-world usage.

🧠 Example: DBML → SQL Conversion

DBML Input

Table users {
  id int [pk, increment]
  email varchar(255) [unique, not null]
  created_at timestamp
}
 
Table posts {
  id int [pk, increment]
  user_id int [ref: > users.id]
  title varchar
}

PostgreSQL Output (Preview)

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMP
);
 
CREATE TABLE posts (
  id SERIAL PRIMARY KEY,
  user_id INT,
  title VARCHAR,
  CONSTRAINT fk_user
    FOREIGN KEY (user_id)
    REFERENCES users(id)
);

The export preserves:

• Table order
• Relationships
• Constraints
• Readable formatting

⚙️ Supported Source & Target Types

The export system supports multiple schema sources and SQL targets:

export type SourceType =
  | "dbml"
  | "mysql"
  | "postgres"
  | "json"
  | "mssql"
  | "postgresLegacy"
  | "mssqlLegacy";

This enables:

• DBML → SQL
• SQL → DBML → SQL (round-trip workflows)
• Legacy database compatibility

💡 Best Practices Before Running Exported SQL

• Always review SQL before execution
• Run exports in staging or local environments first
• Use version control for exported SQL files
• Avoid running generated SQL directly on production without validation
• Keep DBML as your long-term schema source

⌨️ Productivity Tips

• Use Ctrl / Cmd + S to save schema before export
• Use Ctrl / Cmd + Q to quickly access export commands
• Combine with SQL → DBML for rapid reverse-engineering
• Use multiple tabs to compare DBML and SQL side-by-side

📦 When to Use DBML → SQL

✅ Summary

The DBML → SQL Export feature turns visual schema design into executable SQL with confidence.
By selecting the correct dialect and previewing output, you ensure safe, predictable database creation while keeping DBML as your single source of truth.

👉 Next Steps

• Explore SQL → DBML for reverse-engineering
• Export diagrams as PNG / JPG for documentation
• Apply themes and layouts before final export
• Share DBML with teams for collaborative design