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

The meta.json files store UI ordering only. The connection files contain the actual schema data: tables, fields, relations, and layout positions. Any team member can right-click a connection and choose “Open read-only” to view the full ERD without needing database credentials.

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.

Engineer A: design and push

Connect to the local database and arrange the diagram. 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.

Push to a dedicated Git repository. That’s the entire responsibility on A’s side - teammates can open the ERD in read-only mode directly, no extra steps needed.

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

Engineer B: pull and open read-only

Clone the repository into ~/schemity/.

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

Right-click the connection and choose “Open read-only”. Schemity opens the full ERD directly - complete schema, full layout, zero credentials needed.

Done. No database, no VPN, no credentials. Just open Schemity, right-click the connection in the sidebar, and view it instantly.

When A updates the schema

A connects to the live database, adjusts the layout, commits, and pushes.

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

B runs git pull, then right-clicks → “Open read-only” again. The updated ERD is visible instantly. No email attachments. No stale Confluence pages. No “which version is current?”

Not just a diagram - a full schema view

This is where read-only mode beats any exported image.

A PNG shows you table names and maybe column names. Schemity’s read-only mode 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 right there.

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 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, 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? Most engineers work against a local database - running on their laptop, in Docker, behind no public IP. An online SaaS tool simply cannot reach it without manual tunneling, which is cumbersome to set up and maintain. Even self-hosted alternatives like chartdb.io require you to install npm or Docker locally just to run the tool - not exactly friendly for non-technical team members who just want to see the schema.

For staging and production databases, the problem is worse. They don’t have public IPs either. 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 all of this. You connect to your local database directly - no tunneling, no firewall changes, no npm install. 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 9 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. Push.

Everyone else clones the repo, right-clicks the connection, and chooses “Open read-only”. That one hour will save every engineer on your team hours of archaeology - and it compounds every time someone new joins.