E-commerce orders
Customer, address, order, line item, product, payment and shipment — the schema behind every checkout, with the order-item join that stores price at time of purchase.
8 tables · 8 relationships
ER Diagram Templates
Eight fully-populated database schemas — every table keyed, every relationship given a cardinality. Open one and it's on the canvas right away. Then talk it into your model: "add a tenant_id to every table, drop Shipment, split Address off Customer."
Pick a template
Every diagram here is rendered from the same structured definition you get when you import it — nothing is a touched-up screenshot. The previews show tables and relationships only, so the shape stays readable at card size; click any one to see it in full, with every column, type and key. "Refine in chat" puts the schema on the canvas and opens the conversation panel, so your first sentence can start changing it; "Use this template" drops it into the editor and leaves the rest to you.
Blog / CMS
Posts, revisions, authors, categories, comments and media, plus the post_tag junction that every content schema needs and every first draft forgets.
8 tables · 8 relationships
Multi-tenant SaaS
Tenants, memberships, plans, subscriptions, invoices and an audit log. The tenant_id that has to be on almost every table is drawn rather than assumed.
8 tables · 8 relationships
Online courses
Courses split into modules and lessons, enrollments joining students to courses, assignments and submissions. A clean three-level hierarchy to adapt.
8 tables · 8 relationships
Inventory & warehouses
Stock levels per location, an append-only movement ledger, suppliers and purchase orders with lines. The model that keeps counts auditable rather than just current.
8 tables · 8 relationships
Hotel booking
Room types versus physical rooms, rate plans, bookings, payments and reviews. The type-versus-instance split that trips up most first-pass booking schemas.
8 tables · 7 relationships
Users, roles & permissions
Two junction tables, groups, and sessions. The access-control schema you redraw at every security review — worth having as a picture before the migration.
8 tables · 8 relationships
Product analytics events
Accounts, devices, sessions, a wide event table with a key-value property side table, and experiment assignment. The shape behind any homegrown tracking pipeline.
8 tables · 7 relationships
How to use these templates
1. Take the schema with the most tables
Counter-intuitive, but it works: pick the template with more tables than you need. Dropping a table you can see is a two-second decision; discovering a missing junction table after the migration has shipped is a much longer afternoon.
2. Open it — the whole schema is already drawn
The diagram is on the canvas the moment the page loads, with a primary key on every table, foreign keys marked, cardinality on every relationship, and many-to-many already resolved into junction tables.
3. Talk it into your model
Open the chat panel and correct it in sentences: "add a tenant_id to every table, drop Shipment, split Address off Customer, make the order-to-payment relationship one to many." The assistant edits the same structured schema you are looking at, so each turn returns a redrawn version rather than a fresh guess.
4. Hand-edit and export
The split view puts the Mermaid source next to the preview for the last few touches. Then SVG for docs that get zoomed, PNG for slides and tickets, or the raw source committed next to the migration it describes.
What is an ER diagram?
An entity-relationship diagram is a picture of stored data: the tables, the columns and their types, which columns are keys, and how many rows on one side relate to how many on the other. It answers "what is persisted and how is it linked" — not "what does the code look like", which is a class diagram, and not "what happens when someone checks out", which is a sequence diagram.
The reason to draw one before writing the migration is cardinality. "A booking has a payment" sounds settled until you draw it and have to choose between one-to-one and one-to-many — and that choice decides whether partial refunds need a schema change six months later. Most of the value of an ERD is extracted while you are drawing it.
Mermaid's erDiagram syntax covers what a design document needs: entities with typed attributes, PK and FK markers, named relationships and the full crow's-foot cardinality set. It is not a DDL dialect — no indexes, no constraints, no defaults. That is the right level for a document people will actually read; the migration file carries the rest.
ER diagram syntax reference
Six things carry almost all the meaning in an ER diagram. Cardinality is where the thinking happens — the crow's foot on one end is the difference between a schema that survives contact with real data and one that needs a migration.
Entity & attributes
Entity { ... }A box is a table. Each line inside is a column, written type first, then name — the reverse of most programming languages, and the single most common syntax slip.
Keys
PK / FKSuffix a column with PK for the primary key and FK for a foreign key; a column can carry both. Marking the FKs is what makes the arrows verifiable instead of decorative.
One to many
||--o{The workhorse. Read it symbol by symbol: || is exactly one on the left, o{ is zero or more on the right. One customer places any number of orders; every order belongs to exactly one customer.
One to one
||--||Exactly one on each side. Genuinely rare — if a row always has exactly one partner row, ask whether the two tables should be one. Optional profile-style extensions are the usual honest case.
Many to many
junction tableNever drawn as a single arrow. Put a junction table in the middle and draw two one-to-many relationships into it — that table is where the extra columns (role, added_at, sort order) end up living.
Relationship label
: "holds"The text after the colon names the relationship, and it is required. Use a verb read left to right — "Warehouse holds StockLevel" — so the diagram forms sentences rather than a web of unnamed lines.
Nothing close enough?
Describe your data model in a sentence or two and let the generator draw the first version — then refine it exactly the same way.
Open the generatorFrequently asked questions
How do I change a template after importing it?
Two ways, suited to different edits. Chat is for structural changes described in words — "add a tenant_id to every table", "split Address off Customer", "drop everything to do with shipping" — and returns a redrawn schema each turn. The split-view editor is for surgical ones: fix a column name, change a type, retitle a relationship. Most people import, talk the shape into place, then polish in the editor.
Does the assistant actually understand the imported schema?
Yes, because the template is structured data rather than a picture or a blob of text. The imported tables, columns and relationships become the conversation's working state, so "delete Shipment" removes that exact table and the relationships attached to it — the assistant is not re-guessing your diagram from a description of it.
How do I draw a many-to-many relationship?
You do not draw it directly — you resolve it. Put a junction table between the two entities and draw a one-to-many into it from each side, the way PostTag sits between Post and Tag in the CMS template. This matches what the database will actually contain, and it gives the extra columns (role, added_at, sort order) somewhere to live.
What is the difference between an ER diagram and a class diagram?
An ER diagram describes stored data — tables, columns, keys and cardinality, with no behaviour. A class diagram describes code — types with methods, inheritance and interfaces. If what you are drawing maps to a schema migration, it is an ERD; if it has methods, it is a class diagram.
Should I use one-to-one or one-to-many?
Ask whether a second row could ever legitimately appear. An order with exactly one payment is one-to-one until you allow partial payments or retries, at which point it was always one-to-many. When you are unsure, one-to-many is the cheaper mistake: it costs an extra join now, whereas the reverse costs a migration later.
Can I turn the diagram into SQL?
Not directly — an ERD deliberately stops short of DDL. It carries tables, columns, types, keys and cardinality, but not indexes, constraints, defaults or collations. It is the design artifact that gets reviewed; the migration is written from it once the shape is agreed.
How many tables can one diagram hold before it stops being useful?
Readability, not the tool, is the limit. Past roughly a dozen tables the relationship lines start crossing and nobody traces them. Split by subject area — orders in one diagram, catalogue in another — and link them from a parent document. The templates here sit deliberately at eight.
Related
AI ER diagram generatorStart from prose instead of a template: describe the tables, get Mermaid.Diagram from JSONPaste a sample payload and let the model infer the entities.Class diagram templatesThe code side of the same domain: types with methods instead of tables.Flowchart templatesFor processes rather than storage: eight fully-branched flows.