You Don't Need a Diagram of All 800 Tables

Disclosure: I build Schemity, a desktop ERD tool - this post is from our blog and uses it for the examples.

TL;DR: A full-schema diagram of an inherited database is a poster, not a map - unreadable by design. Reverse engineer the real schema into Schemity, then carve it into context views: small subject-area diagrams people actually use, offline on your own machine.

The way to document an inherited monster database is not one diagram of everything: reverse engineer the full schema into a desktop ERD tool, then carve it into small context views - one per subject area, each closer to the 20-table page a human can actually read than to the 800-table wall.

The wall deserves a word first, because it keeps getting built. You join a team, or a client hands you their system, and under the application sits a database that has been growing for a decade: hundreds of tables, no documentation, the designers long gone. As Redgate puts it in a piece on modeling legacy databases, you "might not even know about its history and lifecycle". The instinctive response is to point a tool at the database and print everything. One engineer in a Dataedo discussion did exactly that with a roughly 800-table schema - the output came to "60 pages wide and 30 high or so". It went up on the wall, people admired it for a week, and then, in the words of the same thread, "no one ever really used it, it was unusable."

A diagram of everything is a poster, not a map

The full-schema diagram fails for a reason that has nothing to do with the tool: human comprehension does not scale to hundreds of boxes and a thousand crossing lines. Past a few dozen tables, the diagram stops being a model you can reason about and becomes texture - "eye candy," as the thread above calls it. Meanwhile the tools themselves strain: diagramming utilities routinely crash or hang when asked to lay out a whole enterprise schema at once.

The same discussion contains the counter-story, and it is the important half. At a company that owned one of those gigantic tiled posters, an employee drew a single-page diagram of just the 20 main tables - and everyone wanted a copy, including the person who had printed the poster. New hires learned the system from the 20-table page, not the wall.

That is the actual shape of the problem. When you inherit a big database, you do not need one diagram of everything. You need one honest map of what exists, and then a set of small, focused views - each answering one question, each small enough to hold in your head.

Step 1: Reverse engineer the full schema into the ERD

Before you can carve a schema into digestible pieces, you need the real schema - not the wiki's memory of it. Schemity is a desktop ERD tool that will connect to a live database and reverse engineer its schema into an ERD: PostgreSQL, Supabase, MySQL, MariaDB, SQL Server, or SQLite. Reverse engineering a PostgreSQL database to an ERD takes one connection and a few seconds, and because everything runs locally in an offline ERD tool, the schema of that undocumented production system never leaves your machine - a point your IT department will appreciate more than any feature list.

The first render of a huge schema will be dense; that is the nature of the beast. But Schemity treats the main view as something to navigate, not something to frame. A relationship-based auto-arrangement gives you a sane starting layout instead of a random scatter. Every entity carries a footer tally of its fields, indexes, and constraints, so you can size up a table before reading a single line of it - in an unfamiliar schema, the 40-field table with six unique constraints is usually where the business lives. And realtime fuzzy search across entity and field names means "where does anything called invoice live?" is a keystroke, not an expedition across the canvas.

Step 2: Carve the schema into context views

The 20-table diagram everyone photocopied has a name in Schemity: a context view. A context view is a sub-diagram of the main ERD - you pull in just the entities that belong to one subject area, arrange them freely, and leave the other 780 tables out of the frame. Create as many as the schema deserves: one database context view for billing, one for identity, one for the order pipeline. This is how a monster schema turns into a set of ERD perspectives, each the size a human can actually read.

Two design decisions make context views fit the inherited-database problem exactly. First, they are read-only by design: you can move entities and reshape lines to make the view legible, but the schema itself stays untouched, so the main view remains the single source of truth while you explore. Second, an orange dot marks any entity that has relationships to tables you have not pulled into the view - so a focused diagram never silently lies about being complete. In a database you did not design, that dot is your to-do list: it points at the coupling you have not mapped yet, one table at a time.

And as understanding accumulates, write it onto the main view with legends: draw a colored region around the tables you have figured out, name it after the domain, and give its entities a shared color that their relationships inherit. Lock the legend and the whole territory moves as one block when you tidy the canvas. Six weeks in, the main view stops being a wall of anonymous boxes and starts looking like a map of bounded contexts - which is what schema archaeology is ultimately for.

Step 3: Export the views and commit the workspace to Git

Here is the quiet payoff: everything above produces artifacts, not just insight. Each context view exports as an image or as the SQL of exactly its tables, ready for an onboarding doc. The whole workspace is plain local JSON files, so the map you built goes into Git next to the code it explains. And a teammate can open the diagram in read-only mode and explore it without any access to the database connection behind it - the map travels further than the credentials do.

This is the same lesson the poster taught, applied deliberately. A schema visualizer pointed at everything documents nothing; a lightweight ERD tool for software engineers that lets you visualize a PostgreSQL schema offline and then break it into sub-diagrams turns an inherited liability into a documented system. We have written before about why a focused view owes you back the context it removes and why coupling and cohesion cannot be judged from the same view - the inherited database is where those ideas stop being philosophy and start being your first month's survival kit. Pair them with search that answers where any column lives in one keystroke and connection habits that make documenting production feel safe, and the 800-table database stops being something you inherited. It becomes something you own.