AI ER diagram generator

Every database starts the same way: someone describes the application, and a schema gets written down. ERDGenerator closes that gap. Type a plain-English description of your app — «a marketplace with sellers, listings and reviews» — and it proposes a normalized schema you can open straight in the diagram editor. You go from an idea to an editable ERD without writing a single CREATE TABLE first.

What «Describe your app» does

On the home page, next to the SQL input, there is a Describe tab. You write a few sentences about your application, and ERDGenerator turns that text into a concrete schema proposal:

  • Entities for each thing your description names, with columns and column types chosen to fit — a timestamp for «signed up at», a decimal for money, booleans for flags.
  • Primary keys on every table, usually an auto-incrementing id.
  • Foreign keys for each relationship you described, with the right direction — the order book belongs to a user, not the other way around.
  • Join tables for many-to-many relations. If students enrol in courses, you get an enrolments table rather than a comma-separated list of ids in a column.

The proposal is normalized to third normal form: repeating groups are pulled out into their own tables, and each fact lives in one place. The result opens in the visual editor, where it is yours to change.

When to describe instead of pasting SQL

The two inputs solve different problems. If a database already exists, paste its SQL — the parser gives you an exact picture of what is there, down to every constraint, and nothing is invented. The description mode is for the other direction, when the schema does not exist yet:

  • Starting a new project and wanting a first-pass schema in minutes instead of a blank editor.
  • Designing in a review — sketch the domain in a meeting, refine the proposal together, export the DDL afterwards.
  • Learning. Seeing how a paragraph of requirements becomes keys, join tables and types teaches the mapping faster than a textbook chapter. If you are new to the notation itself, start with how to create an ER diagram.

A useful habit: describe first, then paste the real SQL once the database exists, and compare. The differences are usually instructive.

How to write a good description

The generator reads your text literally, so the more of the model you state, the closer the first draft lands. Three things matter most:

  • Name the entities. Not «an app for tracking workouts» but «users, workouts and exercises». Each noun you name becomes a table.
  • State the relationships with their numbers. «A user has many workouts», «a post can have many tags and a tag applies to many posts». The word «many» is what decides between a foreign key and a join table.
  • Mention constraints when you know them. «Emails are unique», «an order must belong to a customer», «a username is at most 30 characters». These become unique constraints, NOT NULL columns and length limits.

An example, and what it produces

Take this description:

A fitness app where users log workouts. Each workout happens on a date and has a duration in minutes. A workout includes several exercises, and for each exercise the user records sets, reps and weight. Users can follow other users to see their workouts.

From that, you would get four tables plus one join table. users with an id primary key and an email; workouts with user_id as a foreign key, a date and a duration_minutes integer; exercises for the catalog of named exercises; and workout_exercises linking workouts to exercises while carrying the per-workout details — sets, reps, weight_kg — as columns on the join table, since a set count belongs to a specific exercise in a specific workout, not to either table alone.

The last sentence is the subtle one. «Users can follow other users» is a many-to-many relation where both sides are the same table, so the proposal adds a follows table with follower_id and followed_id, both referencing users. Getting this pattern right by hand trips up a lot of first schemas; seeing it proposed is half the point.

Refining after generation

The proposal is a first draft, not a verdict. Once it opens in the editor you can rename anything, add or delete columns, change types, and draw relationships the description glossed over, with explicit cardinalities (1:1, 1:N, N:M). Every action is one undo step, and your work autosaves as you go. When the schema looks right, export it — runnable SQL for PostgreSQL, MySQL, SQLite or SQL Server, DBML, a first-draft Prisma schema, or JSON. If you want to understand why the proposal looks the way it does, the normalization guide and the page on many-to-many relationships cover the reasoning.

What happens to your description

Describing your app sends the text to the generation endpoint, where a language model proposes the schema — that step cannot run entirely in your browser. Everything after that is local to your session: the diagram lives in the editor under an anonymous browser cookie, with no account attached, and a shared link is read-only and revocable. If you would rather keep everything client-side, paste SQL instead — parsing never leaves the browser.

Try it

The generator is on the home page, free and without sign-up. Ready-made schemas are in the examples library if you want to see finished diagrams first.