Because Schemity stores diagrams as JSON, you can version control your database diagram in git exactly like source code. This is what it means for database design software to be Git-native.

How do I put a Schemity workspace in my Git repo?

The key step is Import workspace (not New workspace). New workspaces always live under ~/schemity/, but importing lets you point Schemity at any folder - including one inside your Git repository, such as docs/erd/:

  1. In the sidebar, choose Import workspace.
  2. Pick the folder in your repo where the diagram should live.
  3. Give the workspace a name.

Schemity initializes the workspace structure in that folder (so importing an empty repo folder just works) and from then on writes its JSON there. Now the diagram is tracked with the rest of your code.

How do I commit schema changes?

After editing the model, commit it like any change:

git add docs/erd/
git commit -m "Add payments entity and its relationships"

The commit history becomes a timeline of how your schema evolved.

How do I review a schema change in a pull request?

Review what the change will do to a database, not the diagram’s JSON. The JSON is how the design is stored, and its diff is mostly layout: table positions, sizes and line routes moved by the same edit that changed one column, which buries the real change.

There are two ways to see the change in Schemity:

Open the migration file, without pulling anything. This is the default for a reviewer, and it shows what the migration will actually do. On your own diagram, connected to a database:

  1. Press Shift+F7, or choose Analyse a migration file from the Impact button’s dropdown.
  2. Open the migration’s .sql files from the pull request, or paste the SQL. Prisma and Flyway migrations are SQL already; for Alembic or Django, generate the SQL first.
  3. Read the findings: what the migration loses, what can fail on existing rows, what it rewrites or locks, and what depends on it. Preview changes draws the tables it adds, drops and alters.

Pull the branch and open its diagram. Schemity reads the connected database again on open, so against a database still on the old schema it shows where the design in the pull request and the database differ: new tables with a dashed border, entities, fields, constraints or indexes that are missing or changed, and the affected entities and fields in the preview. This is a comparison, not a migration. Pressing Save takes the database’s side: the diagram is synced to the database with nothing migrated, so the diagram file on your disk then matches your database rather than the branch - do not commit it back.

Use both when a framework or an AI agent wrote the migration. The design and the migration can disagree - a renamed column that the migration drops and adds again, or an index the design has and the migration forgot - and the two previews side by side show it.

For a migration file, the database you analyze it against decides the cost you see. The tables that change are the same against any copy of the schema, but row counts, rewrites, locks and failing rows come from the connected database: against a local database with a few hundred rows, a drop that would lose 400,000 rows in production looks free. For the real price, connect to staging or to production with a read-only user. Neither way applies anything to the database: a migration runs only when you edit the diagram yourself, save, and choose to migrate. See Impact Analysis for what each finding means.

A reviewer who does not run Schemity can still see the change: the author exports the preview as an image with Cmd+E (Ctrl+E on Windows and Linux) and attaches it to the pull request. An AI agent reviewing the pull request can do the same analysis over MCP with analyze_migration_file, and draw it in your open Schemity with show_preview.

What happens if I remove an imported workspace?

If you remove an imported workspace from Schemity’s list, it only forgets the path - the folder and its files are left untouched, so your repo keeps the diagram.

Why keep your ERD in Git?

Your ERD stops being a stale picture in a wiki and becomes living documentation that moves with the code: versioned on the same branch, with history, blame and revert.

Next

Let an AI agent read your schema and stage reviewed edits with AI Agents via MCP.