Create a PostgreSQL ER diagram from SQL

Paste SQL like this

create table accounts (
  id bigint generated always as identity primary key,
  name text not null
);

create table invoices (
  id bigint generated always as identity primary key,
  account_id bigint not null references accounts(id),
  total numeric(12, 2) not null,
  issued_at timestamptz not null default now()
);

The foreign key becomes the relationship between invoices and accounts.

From CREATE TABLE to a diagram

Open the schema designer, choose Import, and paste the DDL. Review parser warnings before replacing or merging with the current canvas. The preview lists the tables it found, so a missing table does not become a silent omission.

After import, arrange the tables around the relationships you are trying to understand. A diagram is most useful when the layout reflects the domain instead of the order the tables happened to appear in a dump.

What the visual check catches

The diagram makes missing foreign keys, one table with too many responsibilities, and awkward dependency chains easier to see. It also exposes naming inconsistencies that are easy to skim past in a long migration.

• A *_id column with no foreign-key constraint
• Join tables that are missing a composite uniqueness rule
• Required relationships represented by nullable columns
• Tables whose names hide the direction of the relationship

Edit the model, then export SQL

You can add or edit tables and columns on the canvas, then open PostgreSQL Export to copy or download the generated SQL. Treat that output as a starting point for a migration: review constraint names, indexes, extensions, data backfills, and deployment locking separately.

What not to paste

Do not paste production credentials or data dumps. The importer needs schema DDL, not INSERT statements. Vendor-specific procedural code and every form of ALTER TABLE may not map to a visual model, so keep the original migration as the source of truth.