ER Diagram Designer
Turn a small relational schema into an editable diagram. Add tables and typed columns, define primary and unique keys, and connect ordered foreign-key columns. The same validated model drives the diagram and the generated PostgreSQL DDL, including self references and cycles.
Key features
- Table and column forms with reference-aware renaming and validation before applying an edit
- Ordered composite primary, unique and foreign keys with strict target-key and type checks
- Required or optional parent relationships and one-child settings backed by NOT NULL and UNIQUE constraints
- A documented PostgreSQL DDL subset with quoted identifiers, comments and precise rejection of unsupported syntax
- Reusable project JSON, two-phase CREATE/ALTER DDL and a downloadable SVG diagram
How to use
- Open the composite-key and circular-reference example, import supported DDL/JSON, or add a table.
- Select a table and apply column, primary-key and unique-key edits. Names are exact identifiers; generated SQL quotes them.
- Select ordered child and parent columns for each foreign key. Set its delete/update actions and apply the relation.
- Review cardinalities and cycle markers. Changing optionality or choosing one child applies real schema constraints.
- Export the applied design as SQL, project JSON or SVG. Save JSON before leaving this page.
Use cases
- Review a tenant-and-customer composite key before adding order relationships
- Explain nullable parent references and one-to-one constraints during a database design review
- Exchange a small cyclic schema using CREATE TABLE followed by ALTER TABLE foreign keys
- Turn supported DDL into a readable table-and-key diagram without connecting to a database
Frequently asked questions
How is this different from the SQL formatter or data lineage designer?
The formatter lays out SQL and summarizes query table references. Lineage follows explicitly declared field dependencies. This tool defines table columns, relational keys, constraint-backed cardinality and DDL that can be reopened as the same normalized schema.
Which SQL can I import?
Only the documented PostgreSQL subset: CREATE TABLE with supported column types, NULL/NOT NULL, primary/unique keys and explicit foreign-key target columns, plus ALTER TABLE ADD CONSTRAINT FOREIGN KEY. DEFAULT, CHECK, indexes, schemas, arrays, MATCH clauses, deferrable constraints and other statements are rejected instead of ignored.
Are composite foreign keys and circular references supported?
Yes. Column order and count are retained, target columns must exactly match an ordered declared primary or unique key, and types must be identical after normalization. This is stricter than every compatibility rule PostgreSQL permits. Generated SQL creates all tables and keys first, then adds foreign keys, so cycles and self references survive import/export.
What do the cardinalities mean?
Each child has one required parent only when all its foreign-key columns are NOT NULL; otherwise it has zero or one under default MATCH SIMPLE behavior. A unique key contained in the child foreign-key columns restricts each parent to at most one related child; otherwise many are possible. A foreign key never requires a parent to have a child.
Can I restore and edit the exported files?
Project JSON uses local-er-v1 and postgresql-subset-v1 with exact properties. Reimport preserves the normalized schema. Generated DDL preserves schema semantics, while comments, original formatting and omitted constraint names are not retained; deterministic names are assigned. SVG is an illustration, not an editable project format.
Does validation prove the SQL will run on my database?
No database is contacted or SQL executed. This is a bounded design profile with global constraint-name uniqueness and exact foreign-key types. Review compatibility, privileges, existing objects and data before using generated SQL. Limits are 256KiB input/export, 24 tables, 40 columns per table, 300 total columns, 80 primary/unique keys and 80 foreign keys.
Privacy
Schema text, column names and uploaded files stay in page memory. This tool does not upload them, execute SQL, contact a database or automatically save to browser storage or a URL. Downloads and clipboard writes happen only when requested. Native file reading cannot be physically stopped, but cancelled or superseded reads cannot apply their result.
Comments & questions