The most common fate of a database diagram is to go stale. The schema keeps evolving, the diagram doesn’t, and after a few sprints the ERD is worse than useless - it documents a database that no longer exists. Schemity avoids this by treating a reverse-engineered ERD as a living view of the database, not a snapshot.

The live database is the source of truth

For a diagram created from a live connection (see Reverse-Engineer an Existing Database), Schemity re-syncs the ERD against the database and maps your existing diagram onto the fresh schema:

  • Existing entities keep their layout - positions, relationship shapes, and colors stay exactly where you arranged them.
  • New entities simply appear on the diagram, ready to drag into place on The ERD Canvas.
  • Dropped entities, fields, and relationships are removed - if it’s gone from the database, it’s gone from the ERD.

You never re-import into a randomly re-arranged diagram, and you never maintain two versions of the truth by hand. This is a licensed desktop feature.

When re-sync happens

  • Automatically on open. Every time you open a diagram that has a live connection, Schemity pulls the latest schema and applies it. Opening the ERD is refreshing the documentation.
  • On demand with Reset ERD. Use Reset ERD to take fresh database information mid-session - for example right after a migration ran elsewhere.

Carry a layout from another diagram

New entities arrive unarranged, but if their arrangement already exists in another diagram - say the design you drew before implementation - you do not have to redo it. Select those entities in the other tab, copy, and paste into the connected diagram. Paste is merge-aware: for entities that already exist here (matched by name), it transfers only position, size, and color - the color carrying to their relationships - and never touches the schema. A whole context snaps into its designed shape in one paste. See Entities & Fields for the full copy/paste rules.

Drafts wear a dashed border

On a connected diagram, the database decides what is real. An entity that exists only in the diagram - freshly sketched, or pasted from another tab - shows a dashed border until a successful migration creates it in the database. The diagram’s JSON follows the same rule: with a live connection, schema changes persist to the file only after the migration succeeds (offline diagrams save immediately), so the file on disk never records tables the database has not confirmed.

There is no way to sneak a draft past this. When you save, Schemity generates the migration SQL diff for review and lists exactly which entities do not exist in the database yet - so an accidentally pasted entity is caught twice: once by its dashed border, once at save.

What this means for documentation

If you document a production database schema with Schemity, the documentation maintains itself: open the diagram and you are looking at today’s schema, not last quarter’s. Because the diagram is stored as plain JSON, committing after a re-sync gives you a reviewable record of exactly how the schema drifted - see Version Control in Git. Your Context Views stay focused on their domains while the main view remains the ERD single source of truth.

Re-sync is the pull direction; the push direction is the Migration SQL Diff, which turns your diagram edits into ALTER statements for the database. Together they keep diagram and database moving as one.

Why do this offline

Keeping documentation current usually means either manual effort or a cloud service watching your database. Schemity is a desktop ERD tool - the re-sync happens on your machine over your own connection, so a production schema stays where it belongs. No upload, no sync server, nothing for IT to review.