diagram2codeConvert Mermaid ER to GORM (Go)
Generate production-ready GORM (Go) ORM code from your Mermaid ER diagrams in seconds.
🚀 View the Roadmap to see which frameworks are coming next.
How the Mermaid ER to GORM (Go) 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
GORM (Go) code 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 GORM (Go)
- one Go struct per table with exported PascalCase fields
- gorm struct tags: column names, primaryKey, uniqueness, not-null
- association fields for one-to-many, many-to-one, one-to-one, and many-to-many relationships
- ON DELETE constraint tags only when the diagram declares them — no surprise cascades
- json tags alongside the gorm tags, ready for API serialization
Type mapping: Mermaid ER to GORM (Go)
Diagram column types are logical — the generator maps each one to the idiomatic GORM (Go) type. These are the exact mappings the engine uses:
| Diagram type | GORM (Go) type | Notes |
|---|---|---|
int | uint | GORM's conventional PK type |
string | string | |
text | string | |
decimal | float64 | |
boolean | bool | |
date | time.Time | |
timestamp | time.Time | imports time automatically |
uuid | string | |
bigint | uint64 | |
blob | []byte |
Keys, relationships, and enums
`int id PK` becomes `ID uint` tagged `gorm:"primaryKey"` — the GORM convention that AutoMigrate recognizes as an auto-increment key. Nullable columns become pointer types (*string, *time.Time).
Each relationship generates both sides: the FK scalar field on the child, a parent navigation field (`User User`), and a slice on the parent (`Posts []Post`). Cascade tags are only added when the diagram explicitly sets onDelete.
`::ENUM(active, inactive)` generates a named Go string type with typed constants for each value, and the struct field uses that type — so invalid states fail at compile time, not at runtime.
Frequently asked questions
Do the generated structs work with GORM AutoMigrate?
Yes — fields carry primaryKey, not-null, unique, and column tags that AutoMigrate reads directly. The same diagram can also generate plain SQL DDL if you prefer explicit migrations.
How are nullable columns represented in Go?
As pointer types: a nullable string becomes *string, a nullable timestamp *time.Time. Non-nullable columns use value types.
What does an enum column become in Go?
A named string type plus typed constants (e.g. type Status string, StatusActive Status = "active"), giving you compile-time safety GORM tags alone cannot provide.
Will relationships cascade deletes by default?
No. Constraint tags like OnDelete:CASCADE are emitted only when your diagram declares them via ::RELATIONSHIP[onDelete: CASCADE] — mirroring how the SQL generators behave.