Export SQL DDL from Dr.ERD — PostgreSQL 18 beginner guide

1. Prepare the three-table model and a PostgreSQL 18 target

This lesson continues the model built in the two earlier guides. Check that the target database is PostgreSQL 18 first: Dr.ERD writes DDL for the target stored on the model, so a different target produces different types and constraints.

1. Open the first-erd file from the file list, or create a new model and choose PostgreSQL 18 for the target database.
2. In Chrome or Edge, choose a workspace folder for the .drerd file and the exported file. No account is required.
3. Confirm that the canvas holds three tables and two relationships. If not, work through the beginner ERD guide first.

• The model you export: members, orders, order_items.
• AI chat is optional and is not needed for SQL DDL export. Only the messages you send carry the current ERD context.

• Beginner ERD guide
• Import a Mermaid ERD

2. Choose SQL in the export menu

Choosing SQL in the toolbar export menu opens the export dialog, where the SQL preview shows the generated DDL. You pick the file name and location in the browser save dialog that appears after you select Export.

1. Choose SQL in the export menu. The entry is named SQL and the extension is .sql.
2. Review the CREATE TABLE and ALTER TABLE statements in the SQL preview.
3. Leave Include comments and Include foreign keys on, which is the default. Turning foreign keys off only removes them; it does not fix a validation error.
4. Select Export, then choose the file name (your model name with .sql) and location in the browser save dialog.

• Dr.ERD does not run SQL. It only writes the DDL to a file.
• The preview text can be selected and copied from the screen.
• Range can limit the export to selected tables, and Include referenced parents pulls in the tables they reference.

3. What to check before exporting

DDL prints exactly what the model holds. Before you export, check the Nullable flags, the primary keys, and the relationship mappings. When something is missing, Dr.ERD reports an error instead of writing DDL.

1. Check that Nullable is off for all ten columns across the three tables. Only columns with Nullable off become NOT NULL.
2. Check that the three primary keys are set: members.id, orders.id, and order_items.id.
3. Check that both relationships map their reference key and foreign key (members.id → orders.member_id, orders.id → order_items.order_id). A relationship created by Mermaid import only carries the FK marker, so you must configure the mapping yourself.
4. This lesson has no identity (auto-increment) columns. You supply the id values in your INSERT statements.

• An unmapped relationship raises "Configure the relationship key and FK mapping."
• A parent column that is neither a primary key nor UNIQUE cannot hold a valid reference mapping, so the export is blocked.
• N:M relationships never gain an automatic junction table, so split them into a junction table before exporting DDL.

4. How to read the generated DDL

The PostgreSQL 18 output splits into CREATE TABLE statements that build the tables and ALTER TABLE statements that attach the foreign keys. Dr.ERD creates every table first and adds relationships afterwards, so running the script from top to bottom always finds the referenced table already in place.

1. In each CREATE TABLE statement, read the column names, types, NOT NULL markers, and the PRIMARY KEY clause.
2. In each ALTER TABLE statement, read FOREIGN KEY (child column) REFERENCES parent table (parent column).
3. Check that the constraint name was derived from your own relationship UUID.

• A constraint name is fk_ plus the start of the relationship UUID. Every relationship gets its own UUID, so a different name than the example is normal.
• ON DELETE NO ACTION ON UPDATE NO ACTION means the database refuses to delete or change a parent row while child rows still point at it.
• Both relationships in this lesson are non-identifying, so the foreign key stays out of the child primary key.
• A foreign key column must match the type of the column it references, or the export stops with a missing or unsupported type error.

5. Example DDL (PostgreSQL 18 output)

Below is what this three-table model produces for PostgreSQL 18. Constraint names come from the relationship UUID, so the values after fk_ differ on your model while the tables, columns, types, and references stay the same.

• Statement order: three CREATE TABLE statements, then two ALTER TABLE foreign keys.
• All ten columns with Nullable off are printed as NOT NULL.
• A different constraint name than the example is still the same structure as long as the referenced columns and referential actions match.

CREATE TABLE "members" (
  "id" BIGINT NOT NULL,
  "name" VARCHAR(100) NOT NULL,
  PRIMARY KEY ("id")
);

CREATE TABLE "orders" (
  "id" BIGINT NOT NULL,
  "member_id" BIGINT NOT NULL,
  "created_at" TIMESTAMP NOT NULL,
  PRIMARY KEY ("id")
);

CREATE TABLE "order_items" (
  "id" BIGINT NOT NULL,
  "order_id" BIGINT NOT NULL,
  "product_name" VARCHAR(100) NOT NULL,
  "quantity" INTEGER NOT NULL,
  "unit_price" NUMERIC(12,2) NOT NULL,
  PRIMARY KEY ("id")
);

ALTER TABLE "orders" ADD CONSTRAINT "fk_11111111222243338444" FOREIGN KEY ("member_id") REFERENCES "members" ("id") ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE "order_items" ADD CONSTRAINT "fk_66666666777748888999" FOREIGN KEY ("order_id") REFERENCES "orders" ("id") ON DELETE NO ACTION ON UPDATE NO ACTION;

6. How MySQL 8.4 and Oracle 19c differ

Dr.ERD writes SQL for the target selected on the model. The same model produces different types and syntax for a different target, so you cannot run the PostgreSQL 18 example unchanged on MySQL or Oracle. The differences are:

1. With MySQL 8.4 (InnoDB) as the target, the Amount domain suggests DECIMAL(18,2); in MySQL, NUMERIC is a synonym of DECIMAL.
2. MySQL TIMESTAMP is limited to 1970 through 2038, so the timestamp domain suggests DATETIME instead.
3. Oracle 19c uses NUMBER(19,0) instead of BIGINT and VARCHAR2(100 BYTE) with a byte length instead of VARCHAR. It has no BOOLEAN type, so no boolean domain is offered.

• MySQL output quotes identifiers with backticks, ends CREATE TABLE with ENGINE=InnoDB DEFAULT CHARSET=utf8mb4, and prints auto-increment columns as AUTO_INCREMENT.
• Oracle output quotes identifiers with double quotes. Oracle has no ON UPDATE action, so the foreign keys carry no ON UPDATE clause.
• Run the generated DDL on the target it names. Moving it to another database means checking the types again.

7. Verify the saved DDL in a database

Dr.ERD does not run SQL, so you execute the saved file yourself. Use a test database you already have, or wrap the script in one transaction, so a mistake does not leave tables behind. Installing and connecting PostgreSQL is out of scope for this guide.

1. Run the script in a temporary test database, or wrap it in a transaction and roll back. On PostgreSQL you can work between BEGIN; and ROLLBACK;.
2. Check that three tables (members, orders, order_items) and two foreign keys exist.
3. Insert a child row with no parent. INSERT INTO orders (id, member_id, created_at) VALUES (1, 999, NOW()); must be rejected by foreign key validation.
4. Roll back or drop the temporary database when you are done.

• Expected result: three CREATE TABLE statements, two ALTER TABLE statements, and two foreign keys.
• The id columns are not auto-generated, so insert the values 1, 2, 3 by hand.
• If a child row survives without its parent, the foreign key was not applied; check that the DDL matches the target database.

8. Troubleshooting

Five situations come up most often between export and execution.

• No primary key: without a primary key on the parent table you cannot configure a reference key mapping. Select Set PK on members.id, orders.id, and order_items.id, then review the relationship.
• Unmapped keys: a relationship created by Mermaid import carries only the FK marker. Configure the reference key and FK mapping in the relationship editor.
• Foreign key type mismatch: the referencing column must match the referenced column’s type, length, and scale. If members.id is BIGINT, orders.member_id must be BIGINT too.
• N:M relationship: Dr.ERD never creates a junction table automatically. Build one yourself, split the relationship into two 1:N relationships, and export again.
• Folder write permission: if the save dialog does not open or the write fails, allow access to the workspace folder again, or pick another folder you can write to.

9. Next steps

Keeping the model and the DDL in step makes review and release easier.

• After a change, save the .drerd file and export SQL DDL again so both stay identical.
• Use Mermaid export for documentation and reviews, and Excel export for spreadsheet-style material.

• Beginner ERD guide
• Import and export Mermaid ERD
• Full user guide
• Open the editor