diagram2codeConvert Mermaid ER to MySQL
Generate production-ready MySQL SQL code from your Mermaid ER diagrams in seconds.
How the Mermaid ER to MySQL conversion works
Mermaid erDiagram is a Markdown-friendly notation rendered natively by GitHub, GitLab, Notion, and Obsidian — which makes it the most common way to keep an ER diagram next to the code it describes.
Entities are blocks of `type name marker` lines (markers: PK, FK, UK, INDEX), and relationships use cardinality arrows like `USER ||--o{ POST : writes` — one-to-many from USER to POST. The converter reads both, plus comment directives for everything the base syntax can't express.
Paste your Mermaid ER source into the editor above and the engine parses it into an
intermediate schema — tables, columns, relationships, indexes — then generates
MySQL DDL from that model. Anything the diagram
syntax can't express (NOT NULL, defaults, enums, CHECK constraints, composite indexes)
you add with comment directives like %% ::NN, ::DEFAULT(now()) on the line
above a column. The Mermaid ER reference documents the
full vocabulary.
What the generator emits for MySQL
- CREATE TABLE statements with backtick-quoted identifiers, ready for InnoDB
- AUTO_INCREMENT primary keys for single integer PK columns
- inline ENUM(…) column types for ::ENUM(...) columns
- ALTER TABLE … ADD CONSTRAINT foreign keys with ON DELETE / ON UPDATE actions
- inline COMMENT column options and COMMENT = table options
- CREATE INDEX / CREATE UNIQUE INDEX for composite and named indexes
Type mapping: Mermaid ER to MySQL
Diagram column types are logical — the generator maps each one to the idiomatic MySQL type. These are the exact mappings the engine uses:
| Diagram type | MySQL type | Notes |
|---|---|---|
int | INT | INT AUTO_INCREMENT when it is the auto-increment primary key |
string | VARCHAR(255) | use varchar(n) in the diagram to control length |
text | TEXT | longtext / mediumtext map to their native equivalents |
decimal | DECIMAL | decimal(10,2) passes precision through |
boolean | TINYINT(1) | the MySQL convention for booleans |
date | DATE | |
timestamp | DATETIME | |
uuid | CHAR(36) | stored as the canonical text form |
bigint | BIGINT | |
blob | BLOB |
Keys, relationships, and enums
A single `int id PK` column becomes `` `id` INT AUTO_INCREMENT PRIMARY KEY ``. Composite primary keys emit a table-level `PRIMARY KEY (a, b)` without auto-increment.
Relationships emit `ALTER TABLE … ADD CONSTRAINT` statements with deterministic `fk_<table>_<column>` names — important on MySQL, where anonymous constraints make later migrations painful. ON DELETE / ON UPDATE actions come from the ::RELATIONSHIP directive.
MySQL supports enums natively on the column, so `::ENUM(active, inactive)` emits `status ENUM('active', 'inactive')` inline — no separate type object, no CHECK constraint.
Frequently asked questions
Does the generated MySQL DDL use native ENUM columns?
Yes. ::ENUM(...) values are emitted as an inline ENUM(…) column type, which MySQL validates at the storage layer. PostgreSQL output uses CREATE TYPE instead; SQLite and Oracle fall back to CHECK constraints.
How are booleans represented?
As TINYINT(1), the MySQL convention. Most drivers and ORMs read TINYINT(1) back as a boolean automatically.
Are identifiers quoted for MySQL?
Yes — with backticks. A table named `order` (a reserved word) generates valid DDL because every identifier is backtick-quoted.
Why are foreign keys added with ALTER TABLE instead of inline REFERENCES?
Adding constraints after all CREATE TABLE statements makes the DDL order-independent — a child table can be declared before its parent in the diagram and the script still runs cleanly.