Beauty Diagram
Diagram type

Mermaid ER Diagram Syntax & Examples

Reference for Mermaid ER diagram syntax — entities, attributes with PK/FK, cardinality notation (||--o{), relationship labels, and aliases. Copy-paste schema examples.

Syntax reference, layout guidance, and ready-to-open examples for this diagram type.

At a glance

A syntax reference for Mermaid's `erDiagram` grammar — read this when you need the exact cardinality notation, attribute syntax, or relationship label format, then try the result in the editor.

What is a Mermaid ER diagramBasic syntax — erDiagram + relationship linesCardinality notation — crow's foot symbolsAttributes — fields with type, PK, FKIdentifying vs non-identifying relationshipsCommon patterns & gotchas
Rendered proof
ER diagram with users, orders, and line items.
Theme · Brutalist
Open this diagram in editor
JOIN TABLE MODEL places contains referenced_in USER id string PK email string name string ORDER id string PK userId string FK placedAt datetime LINE_ITEM id string PK orderId string FK productId string FK quantity int PRODUCT id string PK name string price decimal
View Mermaid sourcePlain-text diagram syntax — copy or edit directly.
diagram.mmd
1erDiagram
2  USER ||--o{ ORDER : places
3  ORDER ||--|{ LINE_ITEM : contains
4  PRODUCT ||--o{ LINE_ITEM : referenced_in
5  USER {
6    string id PK
7    string email
8    string name
9  }
10  ORDER {
11    string id PK
12    string userId FK
13    datetime placedAt
14  }
15  LINE_ITEM {
16    string id PK
17    string orderId FK
18    string productId FK
19    int quantity
20  }
21  PRODUCT {
22    string id PK
23    string name
24    decimal price
25  }

What is a Mermaid ER diagram

An entity-relationship diagram describes the structure of a relational data model — entities (tables / record types), their attributes (columns), and the relationships between entities including cardinality. Mermaid ER diagrams follow the standard Chen / crow's foot notation used in database design tools. They are the right shape for schema reviews, migration plans, data-model onboarding documentation, and any discussion that hinges on how records relate. For runtime object models (with methods and behaviour), use a class diagram instead — ER is purely about persistent data structure.

Basic syntax — erDiagram + relationship lines

Every ER diagram starts with `erDiagram`. The simplest declaration is just a relationship between two entities: `USER ||--o{ ORDER : places`. Mermaid auto-creates the entities from the relationship — declaring them separately is optional. The colon-prefixed label (`places`) describes the relationship in human terms. Entity names are conventionally written in uppercase (matching SQL table naming conventions) but Mermaid does not enforce this; lowercase or mixed-case names work fine. Each relationship line stands on its own — no curly braces needed unless declaring attributes.

  • `erDiagram` — diagram type keyword (always first)
  • `A ||--o{ B : label` — basic relationship with cardinality and label
  • Entity names auto-created from relationships; explicit declaration optional

Cardinality notation — crow's foot symbols

Mermaid uses standard crow's foot notation for cardinality at each end of a relationship. The notation has two parts per side: the minimum and the maximum. `||` is exactly one (one minimum, one maximum). `|o` is zero or one (optional). `o{` is zero or many. `}|` is one or many (at least one). The reading order is `left-side -- right-side` — so `USER ||--o{ ORDER` reads as "exactly one USER, zero-or-many ORDERs" (a user can have zero or more orders, and each order belongs to exactly one user). Getting the cardinality right is the single most important part of an ER diagram — it determines whether the schema is correct.

  • `||` — exactly one (mandatory single)
  • `|o` — zero or one (optional)
  • `o{` — zero or many
  • `}|` — one or many (at least one)
  • Reading: `LEFT-cardinality--RIGHT-cardinality LEFT-side--RIGHT-side`

Attributes — fields with type, PK, FK

Attributes are declared inside an entity block. The format is `type name modifier comment`: `string id PK "primary key"`. The type can be any database type (`string`, `int`, `decimal`, `datetime`, `boolean`). The modifier identifies key roles: `PK` for primary key, `FK` for foreign key, `UK` for unique key. The optional comment at the end (in quotes) clarifies anything not obvious from the name. Most ER diagrams show only the keys and a handful of identifying attributes — listing every column makes the diagram unreadable. Focus on the columns that matter for understanding the relationships.

Identifying vs non-identifying relationships

Mermaid distinguishes identifying relationships (where the related entity cannot exist without its parent) from non-identifying ones using line style. The solid line `--` is identifying — the child's existence depends on the parent. The dotted line `..` is non-identifying — the child can exist independently. For example, `ORDER ||--|{ LINE_ITEM` is identifying (line items don't exist without an order), while `USER ||..o{ ADDRESS` could be non-identifying (an address record might exist in your contact book independently of any user). Most schemas don't need both notations, but for normalised database designs the distinction matters for foreign key constraints.

Common patterns & gotchas

Three patterns dominate real ER diagrams. One-to-many (`PARENT ||--o{ CHILD`) is the most common — a User has many Orders, an Order has many LineItems. Many-to-many (`POST }o--o{ TAG`) uses a junction table in the actual schema; in the diagram you can either show the junction explicitly (POST ||--o{ POST_TAG }o--|| TAG) or hide it with a direct many-to-many edge for clarity. Self-referencing (`EMPLOYEE ||--o{ EMPLOYEE : reports_to`) is for hierarchies — needs a label since the cardinality alone doesn't communicate the meaning. The most common gotcha: cardinality reads in the order written, so getting which side is which matters — `USER ||--o{ ORDER` is different from `USER o{--|| ORDER`.

  • Cardinality read order matters: left-symbol--right-symbol matches LEFT-entity--RIGHT-entity
  • Self-referencing relationships need a label to be meaningful
  • Show only the attributes that matter for relationships — full column lists clutter
FAQ

Mermaid ER Diagram Syntax & Examples — frequently asked questions

How do I express cardinality in Mermaid ER syntax?

Use crow's foot notation between two entities: `USER ||--o{ ORDER` reads as "exactly one USER, zero-or-many ORDERs". The symbols are paired — minimum then maximum at each end. `||` exactly one, `|o` zero or one, `o{` zero or many, `}|` one or many. The reading order matches the writing order: `LEFT-symbols--RIGHT-symbols LEFT-entity--RIGHT-entity`. Getting cardinality right is the single most important part — it determines whether the schema your diagram describes is actually correct.

How do I add attributes to an entity?

Wrap the attribute list in braces after the entity name: `USER { string id PK string email string name }`. Each attribute is `type name modifier optional-comment`. Common types: `string`, `int`, `decimal`, `datetime`, `boolean`. Common modifiers: `PK` (primary key), `FK` (foreign key), `UK` (unique key). Optional comments go in quotes after the modifier. Most ER diagrams should show only the keys and a few identifying attributes — listing every column makes the diagram unreadable.

How do I show a many-to-many relationship?

Two options. The compact form uses `}o--o{` to show the many-to-many directly: `POST }o--o{ TAG : tagged_with`. The explicit form shows the junction table in between: `POST ||--o{ POST_TAG ||--|| TAG`. The explicit form matches the actual database schema (where the relationship is implemented via a junction table) but adds visual clutter. Use the compact form for high-level data models, the explicit form when the junction table itself carries meaningful columns (timestamps, ordering, metadata).

What's the difference between identifying and non-identifying relationships?

Solid lines (`--`) mean identifying — the child entity cannot exist without its parent (LineItems don't exist without an Order). Dotted lines (`..`) mean non-identifying — the child can exist independently (an Address might exist in your contact book without belonging to any User). Most teams use solid lines exclusively and ignore the distinction; it only matters in normalised database designs where the difference affects foreign key constraints and cascade-delete behaviour.

When should I use a class diagram instead of an ER diagram?

Use an ER diagram for the storage model — entities, attributes, relationships in a relational schema. Use a class diagram for the runtime object model — types, methods, inheritance, composition. ER is purely about persistent data structure; class diagrams add behaviour and lifecycle dependencies. Onboarding documentation for a typical service application often shows both side by side: the ER diagram for what gets stored, the class diagram for the in-memory model that operates on it.