There is no single best tool to visualize a database schema, because the tools solve different problems: some help you design a schema that does not exist yet, some let you explore a live database, and some generate documentation from a schema in a pipeline. This comparison covers twelve widely used options, what each takes as input, what it produces and where it fits, so that you can pick by workflow rather than by screenshot.
Three kinds of tool#
Before the list, a way to sort it. Design tools start from a blank canvas or a text DSL and can usually export SQL; they shine before the first migration is written. Explorers connect to a running database and draw what is there; they are for understanding an existing system interactively. Generators run without a screen, take a database or the migrations that build one, and write files that go into a repository or a docs site; they are what keeps documentation current. Several tools straddle two categories, which the table notes.
The tools#
1. dbdiagram.io#
dbdiagram.io is a browser editor where you write the schema in DBML, a small text language, and the diagram renders next to it. It imports DDL from the common engines and exports SQL, images and PDF. Best for designing a new schema and discussing it, and for teams that like a text source they can keep in version control. It does not know about your migrations; when they change, the DBML has to be updated by hand.
2. DBeaver#
DBeaver is an open-source desktop SQL client that draws an ER diagram for any connected schema, lets you rearrange it and export the picture. Best for exploring an unfamiliar database interactively. The diagram is a view of the live connection, so it is always current for that database and never stored with the code.
3. pgAdmin ERD tool#
pgAdmin, the standard PostgreSQL administration tool, includes an ERD tool that can draw an existing database and design new tables, generating the SQL for them. PostgreSQL only, free, and a reasonable choice when your team already lives in pgAdmin.
4. MySQL Workbench#
MySQL Workbench is Oracle's free desktop tool for MySQL with reverse engineering, forward engineering and schema synchronization built around EER diagrams. MySQL only. The natural choice for MySQL teams that want to design visually and generate the DDL from the model.
5. SchemaSpy#
SchemaSpy is a Java command-line tool that connects over JDBC, analyzes the schema and writes an HTML site with tables, columns, constraints, anomalies and relationship diagrams. It runs in CI and has an official Docker image. Best for generated documentation of an existing database, with the caveat that you must provide the database, which usually means running your migrations against a container first.
6. tbls#
tbls is a single-binary Go tool that connects to a database and generates Markdown documentation with ER diagrams, plus a linter for naming rules and a diff command that compares the documentation with the live schema. Output formats include SVG, PNG, Mermaid and PlantUML. Best for repository-native documentation in CI; like SchemaSpy, it needs a database to read from.
7. DbSchema#
DbSchema is a commercial desktop designer that works with many relational engines and several NoSQL databases, with layouts, virtual foreign keys for schemas without constraints, and documentation export. Best for teams that want a full-featured visual designer across many engines.
8. JetBrains DataGrip#
DataGrip is a commercial database IDE that draws diagrams for any selected tables or schema of a connected database, with the same database tooling available inside IntelliJ IDEA Ultimate. Best for developers who already use JetBrains IDEs and want diagrams a click away from the query console.
9. draw.io (diagrams.net)#
draw.io is a free, general-purpose diagramming tool with entity shapes and an option to create tables from pasted CREATE TABLE statements. Best for one-off architecture pictures where the database is one part of a larger drawing. It knows nothing about relationships beyond what you draw, and it does not stay in sync with anything.
10. Mermaid#
Mermaid is a text syntax for diagrams, rendered by GitHub, GitLab and most documentation generators. Its erDiagram type covers entities, attributes with key markers and cardinality. Best for small diagrams inside Markdown files. Layout control is limited and the text has to be maintained or generated; the Mermaid ER diagram guide covers the syntax and its limits.
11. Azimutt#
Azimutt is an open-source web application built for exploring large schemas: import a SQL dump or connect to a database, search across tables and columns, show only the tables you care about, and find join paths between two tables. Best for making sense of schemas with hundreds of tables, where a single full diagram is unreadable.
12. SchemaDrawer#
SchemaDrawer is a hosted service and GitHub Action that takes the migration files themselves, for 22 migration tools, runs them in Docker against a throw-away database of a chosen engine and version, reads the resulting schema and returns an SVG ER diagram. Best for generating a diagram straight from a repository's migrations in CI without hosting a database or the migration tools yourself. It draws tables, columns, primary keys and foreign keys only, and it is an API rather than an editor.
Side by side#
| Tool | Kind | Input | Output | Runs headless |
|---|---|---|---|---|
| dbdiagram.io | Design | DBML text, imported DDL | Diagram, SQL, image, PDF | No |
| DBeaver | Explorer | Live connection | Interactive diagram, image | No |
| pgAdmin ERD | Explorer, design | Live PostgreSQL | Diagram, SQL | No |
| MySQL Workbench | Design, explorer | Live MySQL, model file | EER diagram, SQL | No |
| SchemaSpy | Generator | Live connection (JDBC) | HTML site with diagrams | Yes |
| tbls | Generator | Live connection | Markdown, SVG, PNG, Mermaid, PlantUML | Yes |
| DbSchema | Design, explorer | Live connection, model file | Diagram, SQL, HTML docs | Limited |
| DataGrip | Explorer | Live connection | Interactive diagram, image | No |
| draw.io | Design | Manual, pasted DDL | Diagram file, image | Export only |
| Mermaid | Text | Hand-written or generated text | Rendered SVG in Markdown | Yes |
| Azimutt | Explorer | SQL dump, live connection | Interactive diagram | No |
| SchemaDrawer | Generator | Migration files | SVG | Yes |
How to choose#
Start from your input. If the schema does not exist yet, a design tool with a text source (dbdiagram.io, Mermaid) keeps the discussion versioned. If you need to understand a running system today, an explorer (DBeaver, DataGrip, Azimutt for big schemas) gets you there fastest. If the goal is documentation that stays correct, only a generator will do, and the question becomes whether you feed it a live database (SchemaSpy, tbls) or the migrations (SchemaDrawer).
Then look at your engines and tools. Single-engine tools are excellent inside their world and useless outside it. A team running PostgreSQL and SQL Server, with Flyway in one service and Prisma in another, needs something engine-agnostic.
Finally, decide where the picture lives. A diagram on someone's laptop documents nothing. Whatever tool you pick, the output should end up in the repository, next to the migrations, produced by the pipeline described in keeping your database diagram up to date with CI.
Where SchemaDrawer fits#
SchemaDrawer is the generator to use when the migrations are the input you have and you would rather not run databases and migration tools in your own pipeline. It covers Flyway, Liquibase, Prisma, Django, Alembic, EF Core, Rails, Laravel and the rest of the 22 supported tools on PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and SQLite, in the versions you deploy on. It is free today; this walkthrough shows the API and the GitHub Action, and the tool pages show the file layout each migration tool expects.
Key takeaways#
- Design tools, explorers and generators solve different problems; choose by the problem, not by the prettiest export.
- Only generators keep documentation current, and they need either a live database or the migrations as input.
- Single-engine tools are fine for single-engine teams; mixed shops need engine-agnostic output.
- Whatever draws the picture, commit the result next to the migrations.