How to generate an ER diagram with AI

1. Prepare your schema.sql

Your AI needs the structure of your database: table names, columns, and constraints. If you already have a schema.sql file, you’re ready. Otherwise, export the structure from your database client, or use the schema and migrations in your codebase. You don’t need application rows.

Choose your database below for export instructions and a complete example. Each version describes the same project tracker: four tables, four foreign keys, and tasks that can be unassigned.

pg_dump --schema-only --no-owner --no-privileges -d your_database > schema.sql

-- PostgreSQL. A small project tracker, with no application data.
CREATE TABLE users (
    id bigint PRIMARY KEY,
    email varchar(255) NOT NULL UNIQUE
);

CREATE TABLE projects (
    id bigint PRIMARY KEY,
    name varchar(120) NOT NULL
);

CREATE TABLE project_members (
    project_id bigint NOT NULL REFERENCES projects(id),
    user_id bigint NOT NULL REFERENCES users(id),
    role varchar(20) NOT NULL,
    PRIMARY KEY (project_id, user_id)
);

CREATE TABLE tasks (
    id bigint PRIMARY KEY,
    project_id bigint NOT NULL REFERENCES projects(id),
    assignee_id bigint REFERENCES users(id),
    title varchar(200) NOT NULL,
    external_ticket_id varchar(80)
);

COMMENT ON COLUMN tasks.external_ticket_id IS
    'An identifier from an external issue tracker, not a local foreign key.';

mysqldump -u your_user -p --no-data your_database > schema.sql

-- MySQL 8.x / InnoDB. The same project tracker, with no application data.
CREATE TABLE users (
    id bigint NOT NULL PRIMARY KEY,
    email varchar(255) NOT NULL UNIQUE
) ENGINE=InnoDB;

CREATE TABLE projects (
    id bigint NOT NULL PRIMARY KEY,
    name varchar(120) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE project_members (
    project_id bigint NOT NULL,
    user_id bigint NOT NULL,
    role varchar(20) NOT NULL,
    PRIMARY KEY (project_id, user_id),
    FOREIGN KEY (project_id) REFERENCES projects(id),
    FOREIGN KEY (user_id) REFERENCES users(id)
) ENGINE=InnoDB;

CREATE TABLE tasks (
    id bigint NOT NULL PRIMARY KEY,
    project_id bigint NOT NULL,
    assignee_id bigint NULL,
    title varchar(200) NOT NULL,
    external_ticket_id varchar(80) NULL
        COMMENT 'An identifier from an external issue tracker, not a local foreign key.',
    FOREIGN KEY (project_id) REFERENCES projects(id),
    FOREIGN KEY (assignee_id) REFERENCES users(id)
) ENGINE=InnoDB;

-- SQL Server. The same project tracker, with no application data.
CREATE TABLE dbo.users (
    id bigint NOT NULL PRIMARY KEY,
    email varchar(255) NOT NULL UNIQUE
);

CREATE TABLE dbo.projects (
    id bigint NOT NULL PRIMARY KEY,
    name varchar(120) NOT NULL
);

CREATE TABLE dbo.project_members (
    project_id bigint NOT NULL,
    user_id bigint NOT NULL,
    role varchar(20) NOT NULL,
    PRIMARY KEY (project_id, user_id),
    FOREIGN KEY (project_id) REFERENCES dbo.projects(id),
    FOREIGN KEY (user_id) REFERENCES dbo.users(id)
);

CREATE TABLE dbo.tasks (
    id bigint NOT NULL PRIMARY KEY,
    project_id bigint NOT NULL,
    assignee_id bigint NULL,
    title varchar(200) NOT NULL,
    -- An identifier from an external issue tracker, not a local foreign key.
    external_ticket_id varchar(80) NULL,
    FOREIGN KEY (project_id) REFERENCES dbo.projects(id),
    FOREIGN KEY (assignee_id) REFERENCES dbo.users(id)
);

The rest of this walkthrough uses the PostgreSQL example. To use another version, replace the SQL in the prompt and name your database engine.

project_members joins users to projects. Its two foreign keys double as a composite primary key, so a user can join a project once. IDs are plain bigints the application assigns.

2. Generate the ERD with a prompt

Start a new conversation and paste the prompt below. For your own database, swap the SQL at the end and change “PostgreSQL” to your engine.

Turn the PostgreSQL schema below into a finished visual ER diagram.
Return one complete HTML file in a single code block. I will save it as erd.html
and open it directly in my browser. No install, build step or internet connection.

Use readable table cards, inline CSS and inline SVG relationship connectors.
Give it a warm off-white background, dark text and muted green table headers.
Show every table and column with its exact name and SQL type, plus PK, FK and
unique markers. Explain composite keys without implying each column is unique.
Label each relationship with its foreign-key column and cardinality at both ends.
Derive cardinality from foreign keys, nullability and uniqueness. Include only
declared foreign keys; do not infer links from column names or redesign the schema.

Keep connectors outside the cards and make the whole diagram fit on a laptop screen.
On narrow screens, allow the whole diagram to scroll without disconnecting lines.
Include a text relationship list and a small legend beneath the diagram.
Keep all CSS and SVG inside the file. No JavaScript, external assets or libraries.
List any limitations after the code block.

-- PostgreSQL. A small project tracker, with no application data.
CREATE TABLE users (
    id bigint PRIMARY KEY,
    email varchar(255) NOT NULL UNIQUE
);

CREATE TABLE projects (
    id bigint PRIMARY KEY,
    name varchar(120) NOT NULL
);

CREATE TABLE project_members (
    project_id bigint NOT NULL REFERENCES projects(id),
    user_id bigint NOT NULL REFERENCES users(id),
    role varchar(20) NOT NULL,
    PRIMARY KEY (project_id, user_id)
);

CREATE TABLE tasks (
    id bigint PRIMARY KEY,
    project_id bigint NOT NULL REFERENCES projects(id),
    assignee_id bigint REFERENCES users(id),
    title varchar(200) NOT NULL,
    external_ticket_id varchar(80)
);

COMMENT ON COLUMN tasks.external_ticket_id IS
    'An identifier from an external issue tracker, not a local foreign key.';

The output is one file containing the diagram’s layout, styling, and connections. The prompt asks for table cards and SVG lines, which the browser can render directly. It also asks for a text relationship list, so the meaning remains readable even if a line is awkwardly placed.

Save the result as erd.html, whether it came as a download or a code block, and open it in your browser.

Choose a model

GPT-6 Astra Claude Fable 5.1 Claude Opus 5 GPT-5.6 Sol

Open this diagram ↗ Download the HTML Read the captured response

Open this diagram ↗ Download the HTML

Open this diagram ↗ Download the HTML

Open this diagram ↗ Download the HTML

All four drew the same four relationships and left external_ticket_id unconnected. What differs is the layout, the cardinality notation and the wording of the relationship list.

If something looks wrong

• Raw code in the browser. The file saved as .txt. Rename it.
• Cards collide, or a line crosses a label. That is layout, not schema. Send the assistant a screenshot and ask for a layout-only fix that leaves every relationship as it is.

3. Refine your diagram

You now have an ER diagram you can open and share. Use follow-up prompts to make it easier to read: arrange the tables around a workflow, simplify the detail for a walkthrough, or highlight the relationships you want to discuss.

Continue in the same conversation so the assistant has your schema and generated HTML. In a chat interface, ask for the complete updated file and save it again. In Claude Code or Codex, ask it to edit the file directly.

Arrange the tables around your workflow

Tell the assistant where you want the tables and which connections should be easiest to follow. A screenshot helps when you want to point out a crowded area.

Update the layout of erd.html.
Place projects on the left, tasks in the center and users on the right.
Place project_members below projects and users.
Route connectors through the gaps between cards and keep labels clear of lines.
Keep every table, column, key and relationship unchanged.
Keep the same self-contained HTML format.

Choose how much detail to show

Keep all columns visible when you’re working on the schema. For a team walkthrough, a view with just the keys and a few descriptive fields is easier to follow. Create a separate overview so you can keep both:

Create assignment-overview.html from erd.html.
Include tasks, users, projects and project_members.
Show primary keys, foreign keys and the task title; hide the other columns.
Keep all four relationships and their original cardinalities.
List the hidden columns below the diagram so readers know this is an overview.
Keep erd.html unchanged. Keep the same self-contained HTML format.

For a larger database, ask for a separate view of one area, such as billing or permissions. Name the tables you want included and ask the assistant to list any relationships that lead to tables outside that view.

Highlight the relationships you want to explain

When you’re walking someone through task assignment, make the assignee connection stand out. Keep the rest of the diagram visible so they can see how it fits into the schema.

In erd.html, highlight the connection from tasks.assignee_id to users.id.
Use a thicker line and an accent color, and label it 'Assignee'.
Keep the other relationships visible in a muted color with readable labels.
Add a short note: a task can be unassigned or assigned to one user;
a user can be assigned many tasks.
Keep the layout, columns, keys and relationship cardinalities unchanged.
Keep the same self-contained HTML format.

Open the result and resize the browser. Labels should stay readable and connectors should stay attached to their cards.

Then compare it with your SQL before you share it. Refinements change how the diagram looks, not what it claims, so the table and connection counts should not move. This example has four tables and four foreign-key connections.

4. Add interaction and updates

Once the static diagram is accurate, add controls that help you explore it. Zoom and pan are useful for a growing schema, provided the cards and connectors move together. Keep a reset button and keyboard-accessible controls so readers can recover the initial view.

We’ll also make one schema change: tasks can have an optional reviewer as well as an assignee. The sample includes this migration:

-- Apply after schema.sql, in a disposable tutorial database.
ALTER TABLE tasks ADD COLUMN reviewer_id bigint REFERENCES users(id);

You do not need to run it. For the walkthrough, tell the assistant the migration is applied. In your own project, tell it what actually is, because that is the one fact it cannot work out from the files. Continue in the conversation that created erd.html. In chat, attach the HTML and the migration with the prompt below. In Claude Code or Codex, keep erd.html, schema.sql, and add-reviewer.sql in the working folder:

The migration in add-reviewer.sql is now applied after schema.sql.
Update erd.html to show the resulting database, preserving the existing design.
Keep all table and column names. Check whether the assignee relationship changes.
Label the reviewer and assignee separately; their lines must not overlap.
Add zoom in, zoom out, reset and drag-to-pan controls using inline JavaScript.
Zoom and pan the cards and connectors together, with a usable initial fit.
Keep keyboard-accessible controls and the text relationship list.
Keep the file self-contained and usable offline. No dependencies or network calls.
Do not modify the SQL files. Explain the diagram changes and anything uncertain.

You get one new nullable column and one new line. Reviewer and assignee both run from tasks to users, so the two lines need separate labels and must not sit on top of each other. Check the assignee line survived the update.

Commit the HTML next to your schema and review its diff with the migration. Note the schema source and revision inside the file, because it has no live connection to your database and goes stale the moment someone forgets.

That is the loop. Generate, refine, regenerate when the schema moves. The diagram is only ever as current as the last time you ran it.