Model a database schema your whole team can actually read

A schema diagram is one of the most useful documents a backend team can own, and one of the first to go stale. Someone draws it before launch, it gets a place of honour in the wiki, and then twenty migrations later it describes a database that no longer exists.

The other failure mode is worse: the diagram stays technically current but turns into spaghetti. Foreign-key lines cross straight through three tables to reach a fourth, cardinality is guessed rather than shown, and nobody can tell at a glance whether a user has many orders or exactly one. LetDraw is built to keep schema diagrams both readable and correct, so they are worth keeping around.

Tables that know they are tables

An ER table in LetDraw is not a box with text typed inside it. It is a real table element with typed columns and key markers, so the structure is part of the shape, not a drawing you have to keep in sync by hand.

• Typed columns. Each row carries a name and a type, so id bigint reads like schema, not like a label.
• Key markers. Primary keys and foreign keys are marked on the column, so the reader can see the join surface without hunting for it.
• Editable in place. Add a column, change a type, or rename a field, and the layout keeps up. You are editing a model, not nudging rectangles.

Because the columns are structured, the relationships between tables can be drawn correctly instead of decoratively. That is where cardinality comes in.

Crow's-foot cardinality, rendered natively

A relationship between two tables is only useful if it tells you the shape of the data. One user to many orders is a different world from one user to one order, and a diagram that blurs the two is worse than no diagram. LetDraw draws crow's-foot notation natively on the relationship line, so one-to-many, one-to-one and many-to-many read straight off the connector.

A relationship line should tell you the shape of the data, not just that two tables touch.

When you are modelling code rather than tables, the same connector engine draws proper UML class diagrams with hollow arrowheads for inheritance and the other standard heads. You do not have to hand-draw a triangle and hope it lands in the right place; the notation is native, so an inheritance arrow looks like inheritance to anyone who reads UML.

Foreign-key lines that route around your tables

Here is the detail that decides whether a schema diagram survives past ten tables. As a schema grows, the naive approach draws a straight line from one key to another, and those lines quickly cut through every table in the way. The picture becomes a knot.

LetDraw uses smart routing on foreign-key connectors, so a relationship line treats your tables as obstacles and bends around them. The join between orders.user_id and users.id stays visible even when there are a dozen tables between them. The diagram gets denser as your schema grows, but it does not get illegible, which is the whole point of drawing it.

Start from the SQL you already wrote

You do not have to place a single table by hand. Open the Generate from Code dialog, paste your CREATE TABLE statements, and LetDraw builds the ER diagram for you: tables with typed columns, keys marked, and relationships drawn from the foreign keys. Here is the DDL behind the figure above.

CREATE TABLE users (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email       text NOT NULL UNIQUE,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id     bigint NOT NULL REFERENCES users (id),
  total_cents integer NOT NULL,
  status      text NOT NULL DEFAULT 'pending'
);
-- user_id REFERENCES users(id) becomes the crow's-foot relationship

That REFERENCES clause is what LetDraw reads to place the one-to-many line, complete with the crow's foot on the orders side. From there it is a normal drawing, so you refine and then ship it:

• Rearrange tables, group the ones that belong to one bounded context, and annotate the tricky joins
• Add tables the DDL did not include yet, and draw their relationships by hand with the same crow's-foot heads
• Export to PNG, SVG or PDF for a design doc, or turn the diagram back into Mermaid or D2 when you want it as code again

Why a readable schema is worth the effort

A schema diagram is a contract about how your data fits together, and it only pays off if people trust it. Typed columns and marked keys make it precise; crow's-foot cardinality makes it honest about the shape of the data; smart routing keeps it legible as it grows. Generate the first draft from the SQL you already maintain and the cost of keeping it current drops to near nothing, which is the only way a diagram like this stays alive.

Paste your CREATE TABLE statements and watch the ER diagram assemble itself, keys and all.