Moving a dbdiagram.io Schema to a Connected Model

The DBML draft did its job while the schema was an idea, and now there are tables to deploy and a staging database that has already moved on. To move it, export the project as a SQL DDL script, import that script into DbSchema as a model, and connect the model to the database, where DbSchema compares the two and writes the migration SQL. Tables, keys and references survive the export; notes, colors and table groups do not.

dbdiagram.io exports the schema as SQL DDL for four engines

DbSchema reads SQL DDL, not DBML, so the bridge is a .sql file. From the dbdiagram.io editor, press Export at the top and choose the dialect of the database you will deploy to, so the types and constraint syntax come out right the first time.

From the command line, the open-source DBML CLI does the same with dbml2sql, which writes PostgreSQL when you name no dialect and writes to a file with -o, according to the DBML CLI documentation read on 3 November 2026:

dbml2sql shop.dbml --postgres -o shop.sql

The flag picks the dialect of the generated script:

The same package converts the other way with sql2dbml, so the dbdiagram.io project can live on beside the model if part of the team still reads it there.

Keys and references survive the export, notes and colors do not

The DBML documentation draws the line. Its core syntax covers "all constructs that define database structure and map directly to SQL output": tables, columns, defaults, indexes, relationships and enums, in the words of the DBML syntax documentation. Those reach the SQL file, and from it the DbSchema model. Notes, header and line colors, TableGroup blocks, sticky notes and DiagramView definitions belong to the enrichment and visualization group, which "have no SQL equivalent and are used solely to annotate and support the visualization", as the same documentation puts it. The export has nowhere to put them.

A small PostgreSQL script shows what the SQL side carries. It has an enum, two tables, a unique email and a reference from orders to customers:

CREATE TYPE order_status AS ENUM ('open', 'shipped');

CREATE TABLE customers (
  id    integer PRIMARY KEY,
  email varchar(120) NOT NULL UNIQUE
);

CREATE TABLE orders (
  id          integer PRIMARY KEY,
  customer_id integer NOT NULL,
  status      order_status DEFAULT 'open',
  total       numeric(10,2)
);

ALTER TABLE orders ADD FOREIGN KEY (customer_id) REFERENCES customers (id);

Run against a database, every key in the script is a real constraint:

SELECT tc.table_name, tc.constraint_type, kcu.column_name
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
  ON kcu.constraint_name = tc.constraint_name
WHERE tc.table_schema = 'public'
ORDER BY tc.table_name, tc.constraint_type;

These constraints are what DbSchema reads when it builds the model, so the reference from orders to customers arrives as a foreign key and a line on the diagram, with nothing to redraw.

DbSchema builds the model from the SQL file without a database

The import reads the file as text. Nothing runs against a database, and no connection is needed (DbSchema import documentation).

1. Open the import dialog Pro

   Choose File → Import Model from SQL or Data Files. The Load Model dialog opens.

2. Pick the file Pro

   Under Read from, choose Files, press Choose and pick the .sql file. Leave Read as on Detect automatically.

3. Choose where the tables go Pro

   Under Put the result in, choose A new model and set DBMS to the dialect you exported, then press Load Model. To add the tables to a model you already have open, choose The design open now instead.

A new model opens offline with the tables and the foreign keys between them, and DbSchema opens the script in an SQL Editor below the diagram. Where the parser cannot apply a statement, the Import Report lists the files that hold it, so you see what the model is missing. Importing a model is in DbSchema Pro.

Diagrams and groups in DbSchema replace the lost table groups

The TableGroups that stayed behind were there to make a large schema readable. In DbSchema the same job is done by several diagrams in one model: Diagram → New Diagram (Ctrl+L) opens a new tab for one subject area, and a table can sit on several diagrams while it stays one table in the model. Diagram → Create Group of Tables draws a named, colored box around tables that belong together, and the Edit Group dialog sets its color, which is where the headercolor grouping comes back.

A reference the script left without a constraint gets a virtual foreign key: drag the child column onto the parent column and tick Virtual. DbSchema keeps it in the model and never creates it in the database. The diagrams, groups and virtual foreign keys live in the .dbs model file, which DbSchema Pro saves next to your code in Git.

Schema synchronization shows what changed in the database since the export

This is the only step that changes a database, and the database rarely waits for the model. On staging, someone added a column after the export:

ALTER TABLE orders ADD COLUMN shipped_at timestamptz;

The database now has a column the script never had:

Schema synchronization finds exactly this kind of difference. Connect the model to the database, and DbSchema asks how to bring the two together: Compare, then decide difference by difference reads the database and lists every difference; Write the model into the database generates the CREATE and ALTER statements for a database that does not have the tables yet. In the Synchronize Model and Database dialog, each row has an Action: the left button writes the difference into the model, the right button into the database, and Ignore leaves it. DbSchema shows the SQL of the side you chose before it runs.

To move your own project, export it from dbdiagram.io as SQL, download DbSchema and load the file with File → Import Model from SQL or Data Files. Importing the model, saving it to a file and schema synchronization are in DbSchema Pro, and the 15-day trial in the same installer covers all three; connecting to a database and its diagrams are in the free Community Edition.

Frequently asked questions

How do I export a schema from dbdiagram.io?

Press Export at the top of the editor and choose the dialect of the database you will deploy to. With the DBML CLI, dbml2sql takes --postgres, --mysql, --mssql or --oracle.

Can I import DBML into DbSchema?

DbSchema reads SQL DDL rather than DBML, so export the project to a .sql file first and load it with File → Import Model from SQL or Data Files. Choosing The design open now adds the tables to the model you already have.

Will dbdiagram.io table colors export to SQL?

DBML puts header colors in its enrichment and visualization group, which has no SQL equivalent, so the export drops them. In DbSchema, Diagram → Create Group of Tables puts the tables in a named group whose color you set in the Edit Group dialog.

How do I connect my exported schema to a live database?

Create the connection to the target engine, then choose Compare, then decide difference by difference, or Write the model into the database for an empty one. On a production database, tick Read Only Connection in the connection dialog, and use Highlight to color the connection as Production, Development or Test (connection documentation).

Does the SQL export keep foreign key relationships?

Yes, a reference declared in DBML becomes a FOREIGN KEY constraint, and DbSchema draws it as a line. A relation the script leaves unconstrained becomes a virtual foreign key in DbSchema, kept in the model and never created in the database.

Sources

1. DbSchema import and export documentation
2. DbSchema diagram documentation
3. DbSchema foreign keys documentation
4. DbSchema schema synchronization documentation
5. DbSchema connection documentation