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.
- Relationship lines keep their routes even when a foreign key is renamed - an ORM names constraints its own way (Django hashes them, GORM prefixes
fk_), so a relation is matched by the columns it joins, not only by its constraint name. - 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.
- Virtual relations are kept - a virtual relation exists only in the diagram, so re-sync restores it onto the fresh entities with its routing, unless its columns are gone or a real foreign key now covers them.
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 Refresh & merge. Right after a migration ran outside Schemity - an ORM’s, a teammate’s, an AI agent’s - use Refresh & merge from the Reset ERD dropdown, press Cmd+Shift+R (Ctrl+Shift+R on Windows and Linux), or run it from the command palette. It re-reads the database onto the diagram on screen.
- Start over with Reset ERD. Reset ERD (Cmd+R) re-reads the database onto the diagram as it was last saved and discards unsaved edits. It asks first, because it cannot be undone.
What is the difference between Refresh & merge and Reset ERD?
Both pull the fresh schema; they differ in what they merge it onto.
| Refresh & merge | Reset ERD | |
|---|---|---|
| Merges onto | The diagram on screen, unsaved edits included | The diagram as last saved |
| Result | One unsaved change: Save commits it, Undo takes it back | Applied at once, undo history cleared |
| Use it when | A migration ran outside Schemity and you want to see it | You want to throw away what you changed since the last save |
Refresh & merge is the everyday one. Draw a new table on the connected diagram - it wears a dashed border because the database does not have it yet - let your ORM or coding agent create it, then Refresh & merge: the database confirms it, and the dashed draft turns solid exactly where you drew it. Tables the database added that the diagram did not have arrive placed clear of the rest; tables only the diagram had are dropped, because the database decides what exists. History lists what the refresh changed before you save it.
Can I connect a design I drew offline to a database?
Yes. Connect an offline design to a database that already has tables, or point a connected diagram at another database, and Schemity merges instead of replacing: the database’s schema arrives wearing your design, with positions, sizes, colors, legends, and relation routes kept for every table the database has. The merged diagram opens as one unsaved change, so closing without saving leaves the file as it was. The database type of a diagram is fixed once it exists - a PostgreSQL design cannot be pointed at MySQL.
The same rule applies here as in Refresh & merge: tables only the design has are dropped from the merged result. If the design still holds plans the database does not have yet - contexts not implemented - duplicate the design’s JSON file and connect the copy, so the original keeps the plan. ERD-First Database Design walks through that workflow on a 60-entity schema.
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 app: 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. To carry a whole design over at once, connect a copy of it (see the section above). To carry over a few entities, select them 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 and Refresh & merge are 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 app - 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.