About SchemaDrawer

Why it exists

Every team has a schema diagram somewhere: a wiki page, a whiteboard photo, a file exported from a modelling tool two years ago. None of them match the database. The migrations are the source of truth, but nobody reads a hundred migration files to understand a schema, and every attempt to draw them from the SQL text ends in a parser that handles one dialect badly and the code-based migrations of Django, Rails or EF Core not at all.

SchemaDrawer takes the other road. It starts the database you deploy to, runs your migration tool against it, and asks the engine what it built. That works for every tool and every dialect by construction, and it fails exactly where your deployment would fail, with the same message.

Principles

• Run, don't parse. The migration tool and the engine define the result; nothing else does.
• The engine version is part of the schema. Draw on PostgreSQL 18 if you deploy to PostgreSQL 18.
• Documentation belongs in the pipeline. A diagram that is not regenerated on every change is already wrong.
• Plain outputs, no lock-in. An HTTP API, a bash script and an SVG you keep in your repository.

Who builds it

SchemaDrawer is built by Marek Hudyma, a software engineer who has spent a good part of a career writing and reviewing database migrations. It is free while in early access, and enterprise plans are being shaped with the first teams that ask for them.

Contact

Questions, a tool you are missing, an engine you need, a job that came out wrong: write to [email protected]. Include the job id when it is about a drawing.