ER Diagram Tool: Make an ERD Online

Make an ERD online without dragging a single box

An entity relationship diagram (ERD) is the blueprint of a database. It shows the entities you store — customers, orders, products — the attributes of each one, and the relationships between them. A good ERD helps developers, analysts and stakeholders agree on the data model before anyone writes a migration.

This ER diagram tool lets you make an ERD online from plain text. Write one line per relationship and one block per table, and the diagram is drawn and laid out automatically, complete with crow's foot notation. Because the source is text, you can keep it in your repository next to the code, review changes in pull requests, and update the diagram in seconds when the schema evolves.

How to create an entity relationship diagram

1. Start with `erDiagram`. The first line tells the tool you are drawing an ERD.
2. Add relationships. Write two entity names joined by a relationship symbol and a label, for example CUSTOMER ||--o{ ORDER : places. Entities are created automatically the first time you mention them.
3. Describe attributes. Add a block after an entity name with one attribute per line: a type, a name, and optional keys such as PK, FK or UK.
4. Check the cardinality. Read every relationship in both directions — “one customer places zero or more orders; each order is placed by exactly one customer.”
5. Export. Download a PNG for documentation or an SVG for crisp, scalable diagrams in wikis and design docs.

Crow's foot notation cheat sheet

Cardinality describes how many instances of one entity can relate to another. Each side of the relationship symbol has two characters: the outer one shows the maximum and the inner one the minimum.

• ||--|| — exactly one to exactly one.
• ||--o{ — exactly one to zero or more (the classic one-to-many).
• ||--|{ — exactly one to one or more.
• |o--o{ — zero or one to zero or more.
• }o--o{ — many to many (usually resolved with a junction table).
• Use -- for an identifying relationship (solid line) and .. for a non-identifying one (dashed line), e.g. PERSON }o..o{ CAR : drives.

Attributes, keys and comments

Inside an entity block each line is type name, optionally followed by a key and a comment in quotes. Types can be anything your database understands — int, varchar, uuid, timestamp — and they are shown exactly as you type them. Mark primary keys with PK, foreign keys with FK and unique columns with UK; you can combine them as PK, FK for composite keys in junction tables.

erDiagram
    STUDENT }o--o{ COURSE : "enrols in"
    STUDENT {
        uuid id PK
        string full_name "Legal name"
        date birth_date
    }
    COURSE {
        string code PK "e.g. CS101"
        string title
        int credits
    }

From ER diagram to database

A typical modelling workflow moves from a conceptual model (just entities and relationships), to a logical model (attributes and keys), to a physical model (exact column types for MySQL, PostgreSQL or SQL Server). You can do all three in this tool: start with relationships only, then fill in attribute blocks as the design matures.

When you resolve many-to-many relationships, add a junction entity — like ORDER_ITEM in the example — with foreign keys pointing to both sides. Review each foreign key to make sure it sits on the “many” side of its relationship. Doing this on the diagram is far cheaper than discovering it in production.

Who uses ER diagrams?

Need to show the process that writes to these tables? Draw it with the online flowchart maker. Want to explore the domain first, before thinking in tables? A quick concept map is a great starting point.

• Developers planning a new feature, an API or a database migration.
• Students working on database systems coursework and normalisation exercises.
• Data analysts documenting a warehouse or explaining where a metric comes from.
• Product teams aligning on the data model before building, alongside a use case diagram of what users need to do.

Frequently asked questions