Your tables become a database schema
One card per table, one row per column. Tick the primary keys, pick the table you point to from a list, and the placement works itself out from the relationships. You get a sharp schema for a spec or a technical review. No sign-up.
The + at the bottom of a table adds a column, the one below adds a table, and the × deletes along with whatever it holds. Tick Key for a primary key. Under Relationship, pick the table you point to: the column becomes a foreign key, and you then set the cardinality. You can also paste a block of lines into a Column box, one line per column, and a blank line opens one more table.
What is it for?
A database schema puts an end to people using the same word for different things. It's the artefact you use to scope a data model before building it, to explain an existing one to somebody joining the project, to prepare a data migration, or to attach a readable view to a specification.
It also goes by data model, relational schema, or entity relationship diagram. This tool draws tables, columns and keys, in other words the database as it will actually exist. If you're trying to map out business concepts before talking about tables, this isn't the right artefact.
How to use it
- Name a table at the top of its card, then add its columns with the +. The + Add a table button below adds the next one.
- Tick Key on the column that identifies a row uniquely, usually
id. - For a foreign key, open the Relationship list and pick the table you point to. Two more lists appear: the target column (its primary key by default) and the cardinality.
- Choose whether to show types, pick the font, the text colour and the colour scheme, then download as PNG, JPG, SVG or PDF.
Making sense of cardinalities
A cardinality answers one question: how many rows on one side for a single row on the other? It reads in both directions, and reading it out loud both ways is how you find the right one.
n to 1, the common case
Several rows of this table for one row of the table it points to. A customer places several orders, an order belongs to a single customer. The foreign key goes on the n side: Order carries customer_id, never the other way round. When in doubt, ask it in that direction: the table that can only ever name one row of the other is the one that carries the key.
1 to 1
One row for one row. An employee has a single badge, a badge belongs to a single employee. It's the rarest case, and it's worth asking why the two tables aren't one. Two good answers: the columns are rarely read and you split them out to keep the main table light, or they only exist for some of the rows.
1 to n
The same link, read from the other end. Useful when you're describing a reference table and want to show what depends on it, without moving where the key sits.
n to n, and why it creates a table
Several rows on each side: an order contains several products, a product appears in several orders. This link cannot exist directly between two tables. A column holds one value: if Order carried product_id, it could only ever name one product, and putting it on the other side hits the same wall.
The answer is always the same: a junction table carrying both foreign keys, one row per pair. That's what Order_line does in the example. When you pick n to n from the list, the tool creates that table and its two relationships, and removes the column the action came from, since it was trying to exist in the wrong place. Ctrl+Z takes you back if that wasn't what you wanted.
The reflex right after: that table often carries columns of its own. A quantity, the price at the time of purchase, a date. That's the sign it was needed in the first place.
FAQ
Can I move the tables around by hand?
No, and that's on purpose. The placement follows the relationships: a table referenced by another sits to its left, so reference tables end up on one side and transaction tables on the other. That's what gives you a schema in ten seconds, where a free-form drawing tool asks you to position everything yourself.
Why do some lines pass behind the tables?
Because a line cutting straight across a table makes it unreadable. Links are drawn first and tables on top: a line crossing a table disappears underneath it, which reads as passing behind. Both of its endpoints stay visible, with the n and the 1 telling you the direction.
Can I bring in a schema I already wrote elsewhere?
Yes. Paste a block of lines into a Column box: each line becomes a column, a leading star marks a primary key, the next word is the type, and a blank line opens one more table. Older saves written as text still open as they are, they get converted on the way in.
Can I write the types?
Yes, in the Type column of the grid: decimal, varchar, date. The Types switch hides them all at once, which is often more readable for a business audience.
Does every table need a primary key?
In practice yes. It's what lets you name a row without ambiguity, so you can update it, delete it, and point at it from another table. A table with no primary key is a table you can't talk about.
How many tables?
Up to 14 tables and 24 columns each. Beyond that a schema projected in a meeting stops being readable, so split it by functional area.
Can I come back to my schema later?
Yes. What you type is kept in your browser, and the Save button lets you keep several schemas. Ctrl+Z undoes the last action.
Is it really free?
Yes, no sign-up and no limit on how many schemas you make. The free version adds a small site credit at the bottom of the image and lets you keep up to 3 saved schemas.
All the frequently asked questions, across the seven tools.