DB Planner

How to visualize a SQL database schema (step by step)

Published

A database that only exists as DDL is hard to reason about. An entity relationship diagram makes the shape of the data visible: which tables are central, where the foreign keys point, and what would break if you changed a column. Here is a practical path from a running SQL database to a diagram your team can actually use.

Step 1: Export your schema as DDL

Dump the schema only, not the data. For the common dialects:

# Postgres
pg_dump --schema-only --no-owner mydb > schema.sql

# MySQL
mysqldump --no-data mydb > schema.sql

# MSSQL: Generate Scripts wizard, schema only
# Snowflake
SELECT GET_DDL('SCHEMA', 'MY_SCHEMA');

Step 2: Import the DDL into a diagram tool

Paste the dump into a tool that understands your dialect. DB Planner imports Postgres, MySQL, MSSQL, and Snowflake DDL and converts it to DBML, a readable text format that stays diffable in version control. The diagram renders immediately: tables as cards, primary and foreign keys badged, and relationships drawn as lines between the exact fields involved.

Step 3: Arrange the diagram so it communicates

Auto-layout is a starting point, not an end point. A few rules make a schema readable:

  • Put the central entities (users, accounts, orders) in the middle; satellites around them.
  • Keep lookup tables and enums at the edges, near the tables that use them.
  • Collapse tables you are not discussing so the interesting ones get the space.
  • Group by domain: billing tables together, auth tables together.

In DB Planner you drag tables into place, zoom toward the cursor, and the layout persists for everyone, so the arranging work is done once, not per person.

Step 4: Annotate the decisions

A diagram that only shows structure answers what, not why. Attach notes where questions will come up: a markdown note on the column with the surprising type, a sticky note next to the table pair with the subtle relationship. Future readers, including you, get the reasoning without an archaeology session in the commit history.

Step 5: Keep it alive

The diagram stays useful only if it stays current. Re-import after migrations, or better, make the schema text the source of truth and change it on the board first, together. With a shared real-time board, the diagram becomes the place schema changes are proposed and discussed, rather than documentation written after the fact.

Ready to try it with your own schema? See what DB Planner can do or open the app and paste in a dump.