You spent an afternoon making the diagram right. Entities arranged by domain, relationship lines routed so they don’t cross, colors marking the bounded contexts. It went into the design review, everyone nodded, and the team started building.

Three sprints later, someone opens it and gets confidently lied to. The subscriptions table grew four columns, invoices split in two, and a whole notification domain appeared that the diagram has never heard of. The database moved; the picture didn’t.

This is the most repeated complaint about database diagrams anywhere engineers discuss them. In a Hacker News thread about diagram tools, one commenter concludes that “comprehensive ERDs are becoming rare, and that’s okay. Their value is short-lived due to the high cost of maintenance.” Another puts the structural problem in one line: “the diagram is not the database. So we’ve got two jobs now.” You are hired to design a system, and the diagram quietly hires you for a second position - keeping the picture honest.

The trap: update by hand, or re-import and lose everything

Every ERD tool gives you the same two bad options once the schema drifts.

Option one: maintain the diagram manually. Read the migrations, replay each change onto the canvas by hand, and hope you never miss one. Nobody sustains this. It is exactly the duplicated bookkeeping that makes teams abandon their diagrams - the second job, performed forever, with drift as the penalty for a single lapse.

Option two: throw the diagram away and re-import from the database. Now the schema is accurate and the diagram is wreckage. Most tools re-import into a fresh auto-layout, and users of one popular diagram tool describe the result precisely: “trying to import tables appear in random place and order.” Your afternoon of arrangement - the domain grouping, the routed lines, the analysis that layout encodes - is gone, and you get to do it again after the next migration. The layout work wasn’t decoration; where you place tables is how you show what the schema means, and re-import shreds it on every refresh.

So teams pick a third option by default: they stop opening the diagram. The wiki page keeps its screenshot from last quarter, and new engineers learn the schema by querying information_schema like archaeologists.

Opening the diagram is refreshing it

Schemity’s answer is to make the choice disappear. For a diagram created from a live connection, the database is the source of truth - and the diagram re-syncs itself against it.

Every time you open a reverse-engineered ERD, Schemity pulls the current schema and maps your existing diagram onto it. Re-sync merges what changed instead of starting over:

• Entities that survived keep their layout. Positions, waypoints, colors - the arrangement you invested in stays exactly where you put it.
• New tables simply appear, ready to be dragged into their place in the picture. Placing the new notifications entity where it belongs takes seconds, not an afternoon.
• Anything dropped from the database is dropped from the diagram. No ghost tables documenting a schema that no longer exists.

Need the refresh mid-session - say a migration generated from your ORM models just ran? Reset ERD pulls fresh database information on demand.

Either way, the second job is gone: you never replay migrations by hand, and you never sacrifice your layout to stay accurate. Reverse-engineering the database stops being a one-time import and becomes a standing connection to the truth.

Documentation that maintains itself

Once the diagram tracks the database, things that used to be chores become side effects.

You can finally document a production database schema without scheduling the upkeep, because there is none: whoever opens the diagram is looking at today’s schema, not the screenshot era. The main view stays the ERD single source of truth while context views keep each domain’s focused slice - and since they are read-only perspectives on the same model, they inherit every re-sync too.

And because Schemity is a Git-native ERD tool that stores the whole diagram as plain JSON, a re-sync has one more trick: commit after it, and the diff is the drift report. You can see exactly which tables and columns changed under you since the last commit, reviewable in a pull request like the rest of the ERD that lives in your Git repo.

Re-sync is the pull direction. When you are the one changing the schema, the migration SQL diff pushes your diagram edits back as ALTER statements - the loop that lets you stop hand-translating between SQL and your ERD in either direction.

A diagram you trust is one you never had to remember to update. Schemity is a desktop ERD tool doing this offline, over your own connection - the schema of your production system stays on your machine, and the only thing that leaves the building is the excuse for stale documentation.