Schemity re-syncs a reverse-engineered ERD against the live database every time you open it, preserving your layout - the diagram is a living view of the database, not a snapshot. That matters because 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.
What happens to my diagram when the database schema changes?
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.
How do I re-sync the ERD with my database?
- 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.
What happens if the database is unreachable?
The diagram stays editable. A dropped VPN, a stopped container, or a database that is simply down does not lock you out of your own file:
- Saving still works for changes that need no migration. Recoloring an entity or moving it is a diagram change, and the migration SQL diff is computed from the ERD and the schema Schemity already holds - not by querying the database - so a save with an empty diff never touches the connection.
- Re-sync checks the connection first. If the database cannot be reached, Schemity says so instead of prompting you to apply something, and the diagram and its full undo history are left exactly as they were. You are never dropped onto a loading screen that never resolves.
Structural changes still need the database, because only a successful migration makes them real - see the dashed border rule below. Everything else keeps working offline, which is the point of a desktop ERD tool: the file is on your machine, so your ability to work on it should not depend on a network.
How do I carry a layout over 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.
Why does an entity have 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.
How does re-sync keep my schema documentation current?
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 re-sync offline instead of through a cloud service?
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.