The ERD that lives in your Git repo

You exported a PNG. You pasted it into Confluence. Six months later, three tables have been renamed and two new ones added. The diagram is a lie.

This is the default lifecycle of every ERD that lives outside your codebase. The database moves on. The diagram doesn’t. Eventually someone stops updating it, and it becomes worse than having no diagram at all - because now it actively misleads.

Schemity takes a different approach: your ERD is a plain JSON file that lives in a Git repository, updated deliberately as the schema evolves.

How it works

Schemity stores all your data in ~/schemity/. Each workspace is a folder, and each connection inside it is a JSON file - no proprietary format, no binary blobs, no cloud dependency.

~/schemity/
  meta.json
  my_app/
    meta.json
    connection1.json          # named after your connection
    connection1__offline.json # credential-free snapshot

The meta.json files store UI ordering only. The connection files contain the actual schema data: tables, fields, relations, and layout positions. The __offline variant is a credential-free snapshot that anyone can open without a database connection.

Because these are plain files in a plain folder, ~/schemity/my_app can simply be a Git repository - init it once, push it, and everyone on the team clones it to their own ~/schemity/ folder.

The workflow

Here’s what this looks like in practice, using a Django project with years of migrations and no existing schema diagram. Django here - but the same story applies to any project with accumulated schema history: Rails, Laravel, or anything else that outlived its original team.

You start the dev environment and run migrations. Django’s migration history is the source of truth, but nobody has a visual overview. You pull the latest code, start Docker, and run migrations to bring your local database up to date.

You open Schemity and connect to the local database. Schemity reads the live schema and renders all tables and relations on the canvas. You spend time arranging entities into logical groups - user domain here, billing domain there - adjusting relation routing, adding color-coded legends for bounded contexts. The diagram starts to mean something.

You clone it to an offline ERD. Once the layout is clean, right-click the connection and choose “Clone to offline ERD”. Schemity creates a standalone snapshot - connection1__offline.json - with the full schema and all your layout work, but no database credentials.

You push it to a dedicated Git repository.

cd ~/schemity/my_app
git init
git add .
git commit -m "Initial ERD - document current schema"
git remote add origin <erd-repo-url>
git push -u origin main

Your teammates clone it straight into ~/schemity/.

cd ~/schemity
git clone <erd-repo-url> my_app

They open Schemity, find connection1__offline in the sidebar, click it. Done. No database credentials, no connection setup, no VPN.

After a few sprints, the schema changes. You open connection1 (the live connection), arrange the new entities, right-click → “Clone to offline ERD” to update the snapshot, then commit and push.

cd ~/schemity/my_app
git add .
git commit -m "Update ERD - add subscription and invoice tables"
git push

Everyone runs git pull and sees the updated diagram. No email attachments. No stale Confluence pages. No “which version is current?”

Not just a diagram - a full schema snapshot

This is where the offline ERD beats any exported image.

A PNG shows you table names and maybe column names. The Schemity offline ERD is fully interactive - click any entity to inspect field types, nullable flags, default values, indexes, unique constraints, and check constraints. Everything you saw when connected to the live database is preserved in the snapshot.

New engineers get the full picture, not a flattened screenshot of it. When someone asks “does this field have an index?” or “what’s the check constraint on status?” - the answer is one click away, not buried in a migration file.

Why this matters for long-lived projects

Django projects with mature migration histories are exactly where this shines. The schema has real depth - tables accumulated over years - but the team navigating it has changed. Original authors have left. New engineers join and spend weeks reverse-engineering relationships that should have been documented from the start.

The offline ERD in Git becomes the map. Not a static image that drifts, but a living document that the team actively maintains. Updating it is a deliberate act - arrange the new entities, clone to offline, commit. That deliberateness is the point: it forces you to think about how new tables fit into the existing structure, not just that they exist.

The history is in git log. The context is in the commit messages. The diagram shows not just the current state, but the care with which each domain was organized.

What about SaaS ERD tools?

Some online ERD platforms offer collaboration natively - design a diagram, share a link, done. The more sophisticated ones connect directly to your database, read the live schema, and let you arrange and share from there.

It sounds convenient. But there are two questions worth asking before you hand over that connection string.

Are you comfortable with your schema leaving your network? Table names, column names, and relations reveal how your business works - your pricing model, your user structure, your compliance boundaries. When you connect a SaaS tool to your database, that information flows through someone else’s infrastructure. Most platforms handle it responsibly, but the decision should be deliberate.

How do you even connect? Staging and production databases don’t have public IPs. They’re typically only reachable from within your infrastructure. To let a SaaS tool in, you have to whitelist their IP range - a range shared across all their customers, one that changes every time they add capacity. You’re updating firewall rules for infrastructure you don’t control.

Schemity sidesteps both entirely. You connect to your local database - running on your laptop, in Docker, behind no firewall, exposed to no one. The schema never leaves your machine. No IP whitelisting, no vendor trust decisions, no security review required.

The lightweight part matters too

This workflow only works if the tool is frictionless enough that people actually use it. If opening the ERD requires a license server, a cloud login, or a 500 MB download, nobody will bother keeping it up to date.

Schemity is 8 MB. Installs in seconds. Works completely offline. No account required. A new team member can clone the ERD repo, install Schemity, and have the full interactive diagram open in under a minute.

That’s the bar. Anything heavier and the diagram drifts.

Try it

If your project has been running for a while and nobody can answer “how does billing relate to users?” in under 30 seconds - this is where to start.

Pull the latest code, run migrations, open Schemity, connect to your local database. Spend an hour arranging the canvas properly. Clone to offline ERD. Push.

That one hour will save every engineer on your team hours of archaeology - and it compounds every time someone new joins.