Open Source Data Modeling Tools: A Working List

Open source data modeling tools split into two real categories: tools that let you design a schema visually and generate the SQL to create it, and tools that point at an existing database and draw the diagram for you after the fact. pgModeler and DrawDB are design-first — place tables and relationships on a canvas and export the DDL. DBeaver’s ER diagrams and SchemaSpy work in reverse, reading a live database’s catalog and rendering what is actually there, which is the more honest picture once a schema has drifted from whatever diagram it started as. Reaching for the right one depends on whether the job is designing a new database or understanding one that already exists.

This runs through the open source options worth trying, what each is actually good at, how to choose between a design-first tool and one that reads an existing database, and a few modeling habits — naming, normalization discipline, and keeping the diagram and the database in sync — that matter more than which tool draws the boxes.

pgModeler: design-first modeling for Postgres specifically
DrawDB: a fast browser-based ERD editor
DBeaver Community: ER diagrams from a live connection
SchemaSpy: documentation, not a canvas
Choosing between design-first and reverse-engineered
Modeling habits that outlast any single tool
MySQL vs Postgres modeling: what actually changes
How this fits the rest of the stack
FAQ

pgModeler: design-first modeling for Postgres specifically

pgModeler — PostgreSQL Database Modeler — is GPLv3-licensed and built specifically for Postgres rather than being a generic database tool with Postgres support bolted on. It lets you design a schema visually, export the DDL to create it directly against a real instance, and reverse-engineer an existing Postgres database back into a diagram. Because it is Postgres-specific, it understands Postgres features a generic ER tool often does not — inheritance, custom types, and extension-provided objects — which matters when the design actually depends on them.

The desktop application also validates a design as it is built, flagging a missing foreign key target or a naming collision before the DDL is ever generated, rather than after a failed CREATE TABLE against a real instance. For a team that is Postgres-only and wants the modeling tool to actually understand the engine it targets, rather than a lowest-common-denominator SQL dialect, that specificity is the whole reason to reach for it over a generic alternative.

DrawDB: a fast browser-based ERD editor

DrawDB runs entirely in the browser with no install: define tables by dragging fields onto a canvas or writing a compact DBML-style definition, and export SQL for several different database engines from the same diagram. It is the right choice for a quick whiteboard-replacement session or a shareable design document, rather than a tool meant to be the database’s source of truth over time — there is no live connection to keep it in sync with a real schema as it evolves.

That tradeoff is deliberate rather than a limitation to work around. A tool with zero setup and a link you can send a teammate is genuinely better for the first hour of designing a new feature’s schema than a desktop application with a project file to manage, and DrawDB is built for exactly that hour, not for the months of drift that follow once the schema is live.

DBeaver Community: ER diagrams from a live connection

DBeaver’s free Community edition connects to Postgres, MySQL, and most other common engines and can generate an ER diagram directly from the database’s actual catalog — real foreign keys, not a guess at what the relationships probably are. That makes it the tool worth running first against an unfamiliar database, before writing a single exploratory query, because the diagram reflects what is actually there rather than what a design doc once said it should be. It is a faster first step than manually running a query to list tables in Postgres and piecing the relationships together by hand.

Beyond the diagram, DBeaver is also a full SQL client with autocomplete, a data editor, and export tools, so it tends to become the default place a developer already is when the need for a diagram comes up, rather than a separate tool opened only for that one purpose.

SchemaSpy: documentation, not a canvas

SchemaSpy is not an interactive diagram editor. It is a command-line tool that connects to a database and generates a static HTML site documenting every table, column, index, and relationship, with a diagram scoped to each table’s immediate neighborhood rather than one overwhelming canvas of the whole schema.

docker run --rm -v "$(pwd)/output:/output" schemaspy/schemaspy \
  -t pgsql -host db-host -port 5432 -db appdb -u readonly_user -p '***' -o /output

Because it is a command someone can run rather than an app someone has to open, SchemaSpy fits naturally into a CI job that regenerates the documentation whenever the schema changes, so the docs never go stale relative to the database they describe.

The output is a genuinely browsable static site rather than a single dense image — a table’s page links to every table that references it and every table it references, which turns a large schema’s tangle of foreign keys into something a new team member can click through gradually instead of trying to absorb one enormous diagram at once.

Choosing between design-first and reverse-engineered

The honest way to pick between these tools is to ask which direction the information is actually flowing. Designing a new feature that needs three new tables and a couple of foreign keys is a design-first job — pgModeler or DrawDB, sketch it, export the DDL, run it. Inheriting a database with two years of migrations nobody fully documented, or joining a team and needing to understand what actually exists before touching it, is a reverse-engineering job — DBeaver or SchemaSpy, connect and read.

Most real projects need both at different points, which is why it is worth knowing at least one tool from each category rather than picking a single favorite and forcing every task through it. A design-first tool asked to represent an existing, messily-evolved schema tends to produce a diagram that looks like the original design intent rather than the current reality, which is precisely the wrong picture to be working from when the goal is understanding what is actually there.

Modeling habits that outlast any single tool

Name tables and columns consistently, in one casing convention, rather than mixing snake_case and camelCase across the schema.
Normalize deliberately, and when denormalizing for performance, leave a comment explaining why rather than trusting future memory.
Keep the diagram in version control alongside the migrations that created the schema it describes.
Regenerate a reverse-engineered diagram after schema changes rather than trusting that last month’s export still matches reality.

MySQL vs Postgres modeling: what actually changes

Most of the tools above support both engines from the same interface, so the tool choice rarely forces the database choice. What changes between them in the diagram itself is mostly type handling — Postgres’s native JSON and array types, enum types implemented as actual types rather than a constrained varchar, and how each engine’s indexing options show up in a reverse-engineered model. None of it changes the modeling habits above; it changes what the exported DDL actually contains.

A schema modeled with MySQL-specific assumptions baked in does not port to Postgres for free, and the reverse is also true, so it is worth deciding which engine the design actually targets before exporting DDL rather than assuming the diagram is engine-neutral by default. The practical difference shows up quickly once the schema is live — see building a backend against Postgres for what the modeling decisions above actually look like from the application side.

How this fits the rest of the stack

A diagram is only useful if the database behind it is easy to actually run queries against while the design is still being iterated on. Whichever tool draws the boxes, RunxBuild’s managed Postgres and MySQL give the schema somewhere real to live once the modeling is done — connection limits, backups, and private networking handled, so the step after the diagram is a live database instead of another setup task. The RunxBuild hosting calculator has the database plans if you are pricing out where it should run.

Useful related references:

FAQ

What is the best free tool for a Postgres ER diagram?

DBeaver Community edition is the fastest way to generate an accurate ER diagram from an existing Postgres database, since it reads the real foreign keys from a live connection. pgModeler is the better choice when designing a new schema from scratch, since it is Postgres-specific and exports directly usable DDL.

Is pgModeler actually open source?

Yes, pgModeler is licensed under GPLv3 and its source is publicly available. It is built specifically for PostgreSQL rather than as a generic database tool that happens to support it, which is why it understands Postgres-specific features like inheritance and custom types better than a database-agnostic ER tool typically does in practice.

What does SchemaSpy actually do?

SchemaSpy connects to a database and generates a static HTML site documenting every table, column, index, and relationship, with a diagram scoped to each table’s neighborhood. It is a command-line tool rather than an interactive editor, which makes it a natural fit for a CI job that regenerates documentation on every schema change.

What is DBML and why do some tools use it?

DBML is a compact, human-readable text format for describing tables, columns, and relationships, used by tools like DrawDB to let you define a schema by typing rather than clicking. It is quick to write and easy to version, though it describes a design rather than reading one from a live database.

Should I model in MySQL or Postgres?

Most open source modeling tools support both from the same interface, so the tool choice rarely needs to drive the database choice. The meaningful differences show up in type handling — native JSON, arrays, and real enum types in Postgres versus MySQL’s equivalents — which affects the exported DDL more than the modeling process itself.