Generate from source

Generate an ER diagram from a SQL schema.

Foreign keys already record the relationships. An ER diagram is a rendering of constraints the database is enforcing anyway.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

What it reads

A schema dump, or the migration files if that is what exists, which is more common in application repositories than a checked-in schema. CREATE TABLE gives the entities and their columns, foreign key constraints give the relationships and their direction, unique constraints and indexes indicate which columns matter for access, and NOT NULL together with the key definition determines whether a relationship is optional.

How tables become entities

Each table is an entity. Foreign keys become relationships, with cardinality read from the constraints rather than guessed: a unique foreign key is one-to-one, an ordinary one is one-to-many, and a table whose primary key is composed entirely of foreign keys is recognised as a join table and drawn as a many-to-many relationship rather than as an entity in its own right, which is what makes the diagram match the model in your head instead of the tables on disk.

Why the layout can be trusted

The agent reads the files listed above and emits a semantic graph: components, the tier each belongs to, and the edges between them, with no coordinates anywhere. The ELK layout engine then computes positions and orthogonal edge routing. This is why the output cannot come back with boxes overlapping or arrows crossing through cards, which is the usual failure when a language model is asked to place things on a canvas itself.

Missing foreign keys show up as isolation

Plenty of schemas have implicit relationships, a user_id column with no constraint behind it, and they are invisible in SQL. In a diagram they are visible as a table sitting on its own with nothing connecting it, which is a quick way to find where referential integrity is being maintained by hope rather than by the database.

Your schema stays on your machine

It runs on your machine. With a local Ollama model nothing leaves the laptop at all, and with your own API key the file contents go to the provider you chose and never through us. For a source that is your actual codebase, that distinction is usually the deciding one.

SQL to ER diagram

In the schemaIn the diagram
CREATE TABLEAn entity
Columns and typesAttributes
PRIMARY KEYThe identifying attribute
FOREIGN KEYA relationship with direction
UNIQUE on a foreign keyOne-to-one
Ordinary foreign keyOne-to-many
Composite key of two foreign keysRecognised as a join table, drawn as many-to-many
NOT NULL on the keyA mandatory relationship
IndexesA note on how the entity is accessed

The prompt

shell
$ Read the SQL schema in this directory and draw an entity relationship diagram. Show cardinality and mark the join tables.
FAQ

Questions

Does it connect to my database?

No. It reads files: a dump, migrations, or an ORM schema definition. Nothing needs credentials or network access to a running instance.

Which SQL dialects work?

All the common ones, since it is reading and reasoning about DDL rather than using a dialect-specific parser. Vendor-specific extensions may be summarised rather than represented exactly.

Can it read migrations instead of a schema?

Yes, and it applies them in order to arrive at the current shape. A long migration history takes more reading, so a dump is faster when one is available.

What about an ORM schema?

Prisma schemas, Django models, ActiveRecord and SQLAlchemy definitions all work. They frequently produce a better diagram than raw SQL, because ORM relationship declarations state intent that a bare foreign key does not.

Related