DEV Community: Son Tran

Design First, Ship by Context: One ERD From Sketch to Production

Son Tran — Wed, 15 Jul 2026 10:28:00 +0000

There is a moment in every project where the schema design dies. Not when it's drawn - drawing it is the fun part - but at the handoff, when implementation starts. The diagram says subscriptions has nine fields; someone now has to retype those nine fields as an ORM model, then do it again for fifty-nine more entities. From that day forward the code is the model, the database evolves through migrations, and the diagram becomes a souvenir.

The tooling world's answer is to regenerate the diagram from the code, and the duct tape shows. Prisma users reach for a diagram generator and find schema generation fails under WSL because of a puppeteer dependency three layers down. Rails users run rake erd into a Graphviz-is-not-in-your-path error that persists after Graphviz is installed. Even when these pipelines work, they emit an auto-laid-out artifact - a rendering, not a design.

It doesn't have to work this way. Here is the full loop from a real project - about sixty entities, designed once, shipped context by context - where the diagram stays the design the whole way through. It is an ERD single source of truth workflow in four phases, and at no point does the ERD write a single statement to the database.

Phase 1: Design the whole model up front

Before any code, the entire schema goes onto the canvas: entities aligned, relationship lines routed so they read cleanly, and - this is the load-bearing part - legends drawn around each group of entities to mark the bounded contexts. Identity, catalog, billing, fulfillment: each becomes a named, colored region, and coloring the entities makes every context traceable by hue. This is domain-driven design database schema work in its natural habitat - you are deciding where the seams are while moving boxes is still free.

Design up front does not mean design perfectly. It means capturing everything you currently know about the domain in one picture, so that implementation starts from a map instead of a blank file. Sixty entities sounds heavy; on an infinite canvas with locked legends - drag the region and everything inside moves as one block - it is an afternoon of thinking made visible.

Phase 2: Implement one context at a time, with AI writing the code

Now the trick that makes the design executable. Right-click a legend and Schemity exports the SQL for every entity inside it - the whole bounded context as CREATE TABLE statements in one action. That SQL, plus one line of instruction ("this is the billing module, generate the models"), goes to Claude Code, which writes the ORM models - and sometimes the CRUD layer - for that context.

Then the direction of authority flips, deliberately: migration files are generated from those models and applied by the project's own source code, the way the ORM intends. The ERD provided the spec; the code owns the database from here. Notice what the diagram tool did not do - it never connected as a writer, never applied DDL. The bounded context ERD was the prompt, and a context at a time turns out to be the right unit for AI codegen too: small enough to fit in a model's head, large enough to be a coherent module.

This is a different intersection of AI and ERDs than chatting with a model to design your schema - here the human designed, and AI does the typing. What they share is the privacy shape: private AI database design means your schema goes only where you point it, from a local file on your machine.

Phase 3: Connect to the live database and arrange it once

With the first contexts migrated into the local database, create a live connection and reverse-engineer it. This produces the second diagram of the project - the connected one - and yes, it arrives unarranged. But arranging it is not a redraw; it is a paste. The original design is open in the next tab, so select a context's entities there, copy, and paste into the connected diagram. Schemity's paste is merge-aware: for an entity that already exists in the target - matched by name - it transfers only the visual attributes - position, size, and color - with the color carrying to the entity's relationships. Your designed layout moves between diagrams as data, context by context. (Relationship routing stays per-diagram, since the other end of a line may sit somewhere different here.) Recreate the legends around the groups, and from this point the connected diagram is the living mirror of the real schema.

Phase 4: Refresh, drag, repeat forever

Eventually the code outgrows the original design - it always does. A new table A belongs in context C1, so it goes into the ORM model first, the generated migration runs, and then the update to the diagram is the whole point of this post: open the ERD (or hit Reset ERD), and re-sync pulls the fresh schema with the live database as the source of truth. Table A is simply there, waiting for its place in C1. Drag it in - or, if A was designed in the original tab first, copy that context and paste: the merge-aware paste snaps A to its designed position, size, and color while touching nothing else. Everything already arranged keeps its layout; anything dropped from the database is gone from the picture. Updating the diagram stops being a job and becomes a gesture - a drag, or a paste.

From here the loop is closed: design informs code, code migrates the database, the database refreshes the diagram, and the diagram - grouped back into contexts - informs the next round of design.

The trick: let the diff write the prompt

Adding a table is the easy change. The subtler case is modifying what exists - splitting a field, tightening a type, hanging a new constraint on an old column. The default move is to describe the change to Claude Code in prose and let it edit the model files, and then you inherit a review job: did it interpret "split the address out of customers" the way you meant?

There is a better move, and it uses the diagram as the editor. Make the change on the connected ERD - the same gesture as designing - and press Save. Schemity compares the edited diagram against the live database and shows the migration SQL diff: the exact ALTER statements, in your engine's dialect, that your edit implies. Now don't apply it. Copy that SQL, hand it to Claude Code along with the reason for the change, and it updates the ORM model precisely - because a SQL diff is an unambiguous spec in a way prose never is. The review burden collapses: you already saw the intended change, statement by statement, before the AI touched a file.

From there the loop runs as always: the ORM generates its migration files from the changed model, your source code applies them, and the next refresh brings your own change back to the canvas through re-sync - confirmed by the database itself. One design gesture became a precise diff, the diff became the prompt, the prompt became code, and the code migrated the database. You never left the canvas to specify the change.

The ERD never writes to the database

Run the whole loop again in your head and count the write paths to the database. There is exactly one: the ORM's migrations, executed by your source code. The ERD reads - at reverse-engineering, at every re-sync - and never writes, not because the tool couldn't, but because the workflow makes it unnecessary. Even the migration diff, the one feature built to write, spends its life here as a messenger: a generated spec you hand to the AI, never a statement you run. The canvas keeps the boundary honest, too: anything the database has not confirmed yet - a sketched table, an over-eager paste - wears a dashed border until a successful migration makes it real, and saving warns you about entities that exist nowhere but the picture.

That asymmetry is what lets you point a diagram tool at a database without the low-grade fear that a canvas edit becomes a DDL statement.

It also explains why this works as an offline ERD tool workflow with nothing to configure: both diagrams are plain JSON files in the repo, committed alongside the models they specified, so the design history and the code history live in the same Git log. No sync service, no diagram server, no write credentials - a desktop ERD tool, a local database, and an AI assistant that receives exactly the SQL you right-clicked.

Design first, so the thinking happens while change is free. Ship by context, so every unit of work has a boundary. Let the database drive the diagram after that, so the truth maintains itself. Sixty entities in, the diagram is still the design - which is all anyone ever wanted from an ERD.

Originally published at https://schemity.com on July 14, 2026.

You Have Been Reading ERD Notation Wrong

Son Tran — Mon, 13 Apr 2026 01:58:10 +0000

If you have ever designed a database schema, you have probably drawn an ERD with crow's foot notation. You learned that a circle means optional, a line means mandatory, and a crow's foot means many. You felt confident.

Then you opened your SQL editor and had to guess whether the FK should be NULL or NOT NULL. You were not sure if you needed UNIQUE. And nobody told you that one of the notation symbols cannot be enforced in SQL at all.

This article fixes that. We will cover what each symbol actually means, how to translate notation directly into SQL constraints, and where the notation is richer than what your database can enforce.

Throughout this article, we use one consistent convention: parent entity is always on the left, child entity is always on the right. This makes every notation example unambiguous.

A Brief History

The crow's foot symbol was introduced by Gordon Everest in his 1976 paper "Basic Data Structure Models Explained with a Common Example." Everest used an "inverted arrow" to represent the one-to-many relationship in hierarchical and network data structures, noting that it "inherently and visually depicts the one-to-many relationship" without implying a direction of access.

At that stage, the notation only expressed maximum degree: whether a link could have one or many instances. The minimum degree symbols (the circle and the additional line that express zero vs. one) were added later by other authors and tools as the notation evolved into what we now call crow's foot or Information Engineering (IE) notation.

This origin matters for one reason: the symbol that most engineers obsess over - the minimum degree symbol - was not even part of the original notation. As we will see, there is a strong argument that it still should not be.

The Rule Most Tutorials Miss

Before explaining any symbol, there is one reading rule that almost every tutorial skips:

Symbols are read from the entity outward, in pairs. The symbols closest to an entity describe the constraints on that entity.

This is the part that trips most engineers up. The symbols on the left side of the line describe the left entity. The symbols on the right side describe the right entity. Not the other way around.

[users] || ----- o< [blogs]
         ↑       ↑
   read from   read from
   users out   blogs out

|| near users = a blog must have exactly one user (FK NOT NULL)
o< near blogs = a user can have zero or many blogs

With that rule clear, everything else follows.

The Symbols

Crow's foot notation uses three base symbols:

Symbol	Name	Meaning
`o`	Circle	Zero (optional)
`⎮`	Line	One (mandatory)
`<`	Crow's foot	Many

Each end of a relationship line uses a pair of symbols, read left to right as they visually appear. The symbol closest to the entity is the maximum. The symbol closest to the line is the minimum.

All Valid Combinations

Parent side (left)

Symbol	Min	Max	Meaning
`⎮⎮`	1	1	Child must reference this parent. FK is NOT NULL.
`⎮o`	0	1	Child optionally references this parent. FK is nullable.

Child side (right)

Symbol	Min	Max	Meaning
`⎮⎮`	1	1	Exactly one child. Used in mandatory 1:1 relationships.
`o⎮`	0	1	Zero or one child. Used in optional 1:1 relationships.
`o<`	0	many	Zero or more children. The most common case.
`⎮<`	1	many	One or more children. The parent must have at least one child.

That is the complete set. Four combinations on the child side, two on the parent side. No others exist.

Notation to SQL: The Complete Mapping

Let us use a concrete domain: users, profiles, avatars, blogs, addresses, and attachments.

1. users and profiles - `||——||`

A user must always have exactly one profile. A profile must always belong to exactly one user.

[users] ||——|| [profiles]

CREATE TABLE "profiles" (
  "id" UUID DEFAULT gen_random_uuid(),
  "user_id" UUID NOT NULL,
  "display_name" TEXT NOT NULL DEFAULT '',
  "bio" TEXT NOT NULL DEFAULT '',
  "created_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
  "updated_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);
ALTER TABLE "profiles" ADD CONSTRAINT "profiles_pkey" PRIMARY KEY ("id");
ALTER TABLE "profiles" ADD CONSTRAINT "profiles_user_id_key" UNIQUE ("user_id");
ALTER TABLE "profiles" ADD CONSTRAINT "profiles_user_id_fkey" FOREIGN KEY ("user_id") REFERENCES "users" ("id");

NOT NULL enforces that a profile must belong to a user
UNIQUE enforces that a user can have at most one profile
"A user must have a profile" is not enforced by SQL

2. users and avatars - `||——o|`

A user can have zero or one avatar. If an avatar exists, it must belong to exactly one user.

[users] ||——o| [avatars]

CREATE TABLE "avatars" (
  "id" UUID DEFAULT gen_random_uuid(),
  "user_id" UUID NOT NULL,
  "url" TEXT NOT NULL,
  "created_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
  "updated_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);
ALTER TABLE "avatars" ADD CONSTRAINT "avatars_pkey" PRIMARY KEY ("id");
ALTER TABLE "avatars" ADD CONSTRAINT "avatars_user_id_key" UNIQUE ("user_id");
ALTER TABLE "avatars" ADD CONSTRAINT "avatars_user_id_fkey" FOREIGN KEY ("user_id") REFERENCES "users" ("id");

NOT NULL enforces the avatar must belong to a user
UNIQUE still enforces at most one avatar per user
Note: in SQL, NULL values are not considered equal, so multiple NULL values are allowed even with a UNIQUE constraint

3. users and blogs - `||——o<`

A user can have zero or many blogs. A blog must belong to exactly one user.

[users] ||——o< [blogs]

CREATE TABLE "blogs" (
  "id" UUID DEFAULT gen_random_uuid(),
  "user_id" UUID NOT NULL,
  "slug" TEXT NOT NULL,
  "title" TEXT NOT NULL,
  "description" TEXT NOT NULL,
  "content" TEXT NOT NULL DEFAULT '',
  "created_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
  "updated_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);
ALTER TABLE "blogs" ADD CONSTRAINT "blogs_pkey" PRIMARY KEY ("id");
ALTER TABLE "blogs" ADD CONSTRAINT "blogs_slug_key" UNIQUE ("slug");
ALTER TABLE "blogs" ADD CONSTRAINT "blogs_title_key" UNIQUE ("title");
ALTER TABLE "blogs" ADD CONSTRAINT "blogs_user_id_fkey" FOREIGN KEY ("user_id") REFERENCES "users" ("id");

NOT NULL enforces that every blog must have an owner
No UNIQUE because one user can have many blogs
This is the most common pattern in relational schemas

4. users and addresses - `||——|<`

A user must have at least one address. An address must belong to exactly one user.

[users] ||——|< [addresses]

CREATE TABLE "addresses" (
  "id" UUID DEFAULT gen_random_uuid(),
  "user_id" UUID NOT NULL,
  "line_1" TEXT NOT NULL,
  "line_2" TEXT NOT NULL DEFAULT '',
  "postcode" TEXT NOT NULL,
  "created_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
  "updated_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);
ALTER TABLE "addresses" ADD CONSTRAINT "addresses_pkey" PRIMARY KEY ("id");
ALTER TABLE "addresses" ADD CONSTRAINT "addresses_user_id_fkey" FOREIGN KEY ("user_id") REFERENCES "users" ("id");

NOT NULL enforces that every address must belong to a user
"A user must have at least one address" is not enforced by SQL

5. blogs and attachments - `|o——o<`

An attachment can optionally belong to a blog. A blog can have zero or many attachments.

[blogs] |o——o< [attachments]

CREATE TABLE "attachments" (
  "id" UUID DEFAULT gen_random_uuid(),
  "blog_id" UUID DEFAULT NULL,
  "url" TEXT NOT NULL,
  "created_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
  "updated_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);
ALTER TABLE "attachments" ADD CONSTRAINT "attachments_pkey" PRIMARY KEY ("id");
ALTER TABLE "attachments" ADD CONSTRAINT "attachments_blog_id_fkey" FOREIGN KEY ("blog_id") REFERENCES "blogs" ("id");

|o near blogs = FK is nullable, an attachment can exist without a blog
This is the nullable FK case that most tutorials never explain

The Full Mapping Table

Notation	Side	FK nullable?	UNIQUE?	Reference status
`⎮⎮`	Parent (left)	No	--	`NOT NULL REFERENCES`
`⎮o`	Parent (left)	Yes	--	`NULL REFERENCES`
`⎮⎮`	Child (right, 1:1)	--	Yes	--
`o⎮`	Child (right, 1:1)	--	Yes	--
`o<`	Child (right)	--	No	--
`⎮<`	Child (right)	--	No	--

The Gap: What SQL Cannot Enforce

Here is the part that most tutorials never tell you.

Two of the six notation cases produce identical SQL but mean different things:

Notation	Meaning	Reference status
`o<`	Zero or more children	`NOT NULL REFERENCES`
`⎮<`	One or more children	`NOT NULL REFERENCES`

The SQL is the same. The |< minimum of one is purely a business rule. SQL has no constraint that says "this parent must have at least one child row."

Similarly, ||——|| (user must have exactly one profile) is only half-enforced. The FK NOT NULL UNIQUE ensures every profile has a user and each user has at most one profile. But nothing in SQL prevents you from creating a user with no profile at all.

The unenforced cases

Notation	What SQL enforces	What SQL cannot enforce
`⎮⎮——⎮⎮`	Profile must have a user. At most one profile per user.	User must have a profile.
`⎮⎮——⎮<`	Address must have a user.	User must have at least one address.

In both cases, the gap must be handled at the application level. This is intentional and correct.

Why this gap exists by design

This is not a flaw in crow's foot notation. It is a deliberate design decision.

Carlis and Maguire, in their book Mastering Data Modeling (Addison-Wesley, 2001), argue explicitly against capturing minimum degree constraints on a data model diagram. Their reasoning is direct: minimum degree constraints "are so often false or are a function of processing" rather than a true property of the data itself.

They give a concrete example: a hospital clerk reports that "every patient has at least one diagnosis code." This looks like a valid minimum constraint. But it is false - a patient admitted to the emergency room has no diagnosis code yet. The constraint only holds at a specific stage of the process, not at all times. It is a processing rule, not a data rule.

The same logic applies to your schema. "A user must have at least one address" is almost certainly a processing rule - enforced when a user checks out, or when an order is submitted, not at the moment the user row is created. SQL enforcing it at the database level would break every user registration flow that creates the user first and collects the address later.

Summary

Concept	Key takeaway
Convention	Parent on the left, child on the right
Reading rule	Symbols describe the entity they touch, read outward in pairs
`⎮o` vs `⎮⎮` on parent	Nullable FK vs NOT NULL FK
`o⎮` vs `⎮⎮` on child	Identical SQL, only intent differs both 1:1
`o<` vs `⎮<` on child	Identical SQL, only intent differs both 1:N
The gap	Minimum degree constraints are often processing rules, not data rules

Crow's foot notation is more expressive than SQL. That is not a flaw, it is by design. The notation captures business intent. SQL enforces what it can. Your application handles the rest.

References

Everest, G. C. (1976). "Basic Data Structure Models Explained with a Common Example." Proceedings of the Fifth Texas Conference on Computing Systems, pages 39-46. IEEE Computer Society.
Carlis, J. and Maguire, J. (2001). Mastering Data Modeling: A User-Driven Approach. Addison-Wesley.

This post uses Schemity as the ERD tool for all database diagrams.

Design Data Model for Multi-Tenant RBAC

Son Tran — Mon, 13 Apr 2026 01:51:18 +0000

Part 1: Identity Foundation

Behavior Description

Assume we are building a KPI management platform. Multiple companies can create accounts (tenants) and let their employees access the platform.

A user can be assigned to one or several roles. Their permissions are the sum of those roles' permissions.
A user cannot access features outside their permissions. Even if they know the API specs and bypass the UI, they will still be blocked at the API layer.
Admins can change a user's roles or a role's permissions at any time. The only inconvenience is that the affected user needs to log out and log back in for the changes to take effect.

Sounds straightforward, right? Let's look at what happens under the hood.

Deriving the Data Model from Use Cases

Before implementing, I take time to think about what the system needs to do and what data structures are required to support those use cases.

The first thing we hear in the spec is "multiple tenants." A system that serves multiple companies and their users. That gives us at least two objects to start with: tenants and users.

Note: I use the plural convention for table names throughout this post.

Defining the Relationship Between Tenants and Users

Now we have the foundation, but the relationship between tenants and users is not yet defined. To define it, we need to find the right constraint. There are two cases:

Case 1: One tenant can have many users. One user must use a unique email per tenant.
Case 2: One tenant can have many users. One user can use the same email across different tenants.

Consider this scenario: you are a contractor working for two different companies that both use this platform. If we go with Case 1, the best you can do is maintain two separate emails for two separate tenants on the same system. That is a real inconvenience.

Notice I used the word person instead of user here. Technically, every tenant is independent. There is no good reason to force a person to use a different email just to become a user of another tenant.

Case 2 is the preferred design.

Tenant Identification at Login

This raises a natural question: if a user can log in with the same email across multiple tenants, how do we know which tenant they belong to?

The answer is that when a user logs in, we need to identify the tenant. There are a few approaches:

Ask the user to type a tenant code in the login form. Bad idea.
Provide a typeahead field to help the user find their tenant code. Still a bad idea.
Give each tenant a subdomain or sub-path, such as tenant1.ourplatform.com or ourplatform.com/tenant1. This is the widely accepted approach, especially the subdomain variant. The only tradeoff is that instead of a standard SSL certificate, you need a wildcard SSL certificate.

The Identity Table

Another natural question follows: if users share an email across tenants, can they also share a password?

No. Password policies can differ per tenant, so sharing passwords across tenants is not acceptable. This leads us to a third object: the identities table. An identity represents a user's membership in a specific tenant, containing tenant's specific information.

The relationship is clear: one user can have many identities, and each identity belongs to exactly one tenant. With this simple three-table model - tenants, users, and identities - we satisfy the core constraint cleanly: a person can use the same email across multiple independent tenants.

Recognizing the Many-to-Many Relationship

Look closely at the diagram. Both the N (of 1:N) ends from users and tenants point to the identities table. This is a sign that users and tenants have an N:N relationship - a user can belong to multiple tenants, and a tenant can have multiple users. The identities table is effectively the join table.

With that insight, we can express the data model more precisely:

This post uses Schemity as the ERD tool for all database diagrams.

In Part 2, we will build on this foundation and design the roles and permissions model.

Schemity vs dbdiagram.io: When Your ERD Tool Needs to Outlive the Meeting

Son Tran — Thu, 02 Apr 2026 10:36:02 +0000

There's a moment every software engineer knows.

You're explaining a new feature to a teammate. The schema is in your head. You need something visual, fast, right now. You open a browser tab, type dbdiagram.io, and in three minutes you have a diagram you can paste into Slack.

The meeting happens. Everyone nods. The diagram link dies in the chat history. The actual schema lives in your database, unrelated to what you drew.

That's not a failure of discipline. That's the ceiling of the tool.

This article is for engineers who have hit that ceiling and are wondering what comes next.

The Honest Summary

dbdiagram.io is a fast, focused ERD tool built for quick sketching. Fast, free, browser-based, zero friction. If you need a diagram for a meeting and you'll never look at it again, nothing beats it.

Schemity is what you use when the diagram needs to outlive the meeting. When your ERD is part of your codebase, not a link in Slack. When you want to go from sketch to production schema without switching tools.

If that distinction doesn't matter to you yet, use dbdiagram.io. It's genuinely excellent at what it does.

If it does matter, read on.

Side-by-Side

	dbdiagram.io	Schemity
Interface	Code-based (DBML syntax)	Visual drag-and-drop
Platform	Browser only	Native desktop (macOS, Windows, Linux)
Install size	None (web)	9 MB
Offline	No	Full offline, air-gap ready
Free tier	10 public diagrams, no private, 1 viewer	2-week full trial, all features
Privacy / diagram limits	Upgrade to $9/month required	2-week full trial, fully usable forever after
Your data location	Their servers	Your machine, plain JSON
Git workflow	Manual export	Native: ERD is a JSON file in your repo
Live DB sync	Limited: export SQL scripts only, no direct sync	Yes: reverse-engineer, sync, generate migrations
Migration generation	No	Yes: exact SQL diff, useful for POC and personal projects
Pricing	$9/month	$129 one-time
Keyboard shortcuts	Minimal	Keyboard-first, every action has a shortcut
Multiple tabs	Browser tabs only, no isolated undo history	Yes: native tabs with isolated undo history per diagram
Constraints & indexes	Basic	Full: unique together, check constraints, indexes
N:N relationships	Manual	Auto-generated junction table
Relationship line routing	Fixed, no control	Custom waypoints, smart rerouting, full manual control

Where dbdiagram.io Wins

Let's be honest about this. dbdiagram.io does several things better than almost any alternative.

Speed from zero. No download. No account required. Open browser, start typing, diagram appears in real time. For the specific use case of "I need an ERD right now," nothing is faster.

DBML syntax. If you think in code, DBML is elegant. Define a table in four lines. Copy it from your ORM model. The keyboard never leaves the home row. For engineers who find drag-and-drop slower than typing, this is genuinely the right interface.

Sharing is trivial. One link. Anyone can view it. No account needed for viewers. For sharing with non-technical stakeholders or across teams, the link-based sharing model is hard to beat.

Free. For individual use up to 10 diagrams, you pay nothing. For a lot of engineers, that's enough.

Where dbdiagram.io Hits Its Ceiling

The diagram is not your schema. It's a picture of your schema.

This is the fundamental problem. dbdiagram.io creates a visualization. It doesn't connect to your database. It doesn't track changes. It doesn't generate migrations. When your schema evolves (and it always does), your diagram falls behind. Within weeks, the link you shared is a historical artifact, not a current document.

Your data lives on their servers, not yours.

Every diagram you create in dbdiagram.io is stored on Holistics' infrastructure. If they shut down, your diagrams disappear. If your company requires data locality (SOC 2, ISO 27001, regulated industries), a browser tool storing your schema on a third-party server is a compliance question you'd rather not answer.

The free tier is a public diagram trap.

The free tier gives you 10 diagrams, all public, all visible to anyone with the link, with no private option. The moment you need diagram number 11, or your first private diagram, the pricing jumps to $9/month. For most engineers working on real projects, "public diagrams only" is a non-starter from day one. Your schema is not a public document.

No offline.

Working on a flight. Behind a corporate firewall. On a client site with restricted internet. dbdiagram.io simply doesn't work. For a tool that's supposed to help you think through your architecture, internet dependency is a real constraint.

DBML has a learning curve for non-coders.

If you're the senior engineer who thinks in SQL, DBML feels natural. If you're onboarding a junior, or collaborating with a data analyst who doesn't write SQL daily, the code-first interface creates friction. The visual feedback is good, but the input method is a barrier.

The Three Failure Modes Schemity Was Built to Solve

Schemity wasn't built to compete with dbdiagram.io on its own terms. It was built to solve three specific failure modes that exist across the entire ERD tool market.

Failure Mode 1: The tool defeats you before you start

Visual Paradigm is a serious modeling tool. It does have a Community edition that is free. But finding it is its own obstacle. The download page is cluttered with editions, pricing tiers, and license options that make it genuinely unclear which version to download. Engineers who just want to start modeling end up reading licensing FAQs instead of drawing tables.

Once you do find the right download, the installer takes over. JVM dependency, license wizard, 200+ MB download. Motivated engineers have abandoned it before creating a single entity. The tool defeated them before they opened it.

Schemity is 9 MB. It starts in seconds. There is no IT ticket, no JRE installation, no license wizard, no edition confusion. One download, one version, running immediately. The activation energy is low enough that you open it before the meeting, not after.

Failure Mode 2: Fast sketching and serious design are mutually exclusive

The market has forced a false choice: either use a basic tool that's fast (dbdiagram.io) or use an enterprise tool that's serious (Visual Paradigm, erwin). There is almost nothing in between.

Schemity is drag-and-drop fast. Keyboard shortcuts make it faster still once you're comfortable. But the same tool that handles a five-minute sketch also handles a production schema with 100+ tables, composite unique constraints, check constraints, indexes, and SSH-connected live database sync. It can also generate SQL migrations directly from your ERD, useful for personal projects and fast POCs where you don't need a full migration framework in the way. For production team workflows, your existing migration tooling stays in charge. Schemity sits alongside it, not in front of it.

You don't graduate to another tool. You just use more of the same tool.

Failure Mode 3: Trial expiry holds your work hostage

This is the fear nobody talks about in ERD tool marketing. You spend two hours in a trial. The trial expires. Your diagrams are either gone or locked behind a paywall. And if you were on dbdiagram.io's free tier the whole time, your schema was public to anyone with the link. Serious, sensitive work sitting on a public URL without you realizing it.

Schemity's answer to this is architectural, not a policy. Your ERDs are plain JSON files in ~/schemity/ on your own machine. When the trial expires, Schemity stops receiving updates. You get a single friendly reminder when you open the app, once per session, not a popup that blocks your work or repeats every five minutes. Everything else works exactly as before. Your files are yours. They always were.

If Schemity shuts down as a business tomorrow, your diagrams open perfectly on Monday.

The Git Workflow Nobody Else Has

This is the feature that changes how a team works with database design.

In dbdiagram.io, your ERD lives at a URL. You share the link. When the schema changes, someone updates the diagram manually, if they remember. The diagram and the codebase drift apart over time. Within months, the link you shared in Slack is a historical artifact, not a current document.

Schemity takes a fundamentally different approach, one borrowed from how mature engineering teams already handle infrastructure.

Nobody commits Terraform files inside an application service repo. Infrastructure is a shared concern, it spans services, it has its own change cadence, it deserves its own review. So it lives in its own repo.

Your database schema deserves the same treatment.

The pattern Schemity enables is an ERD repo: a single, dedicated repository that holds the ERDs for every service in your company.

company-erd-repo/
  ├── payment-service/
  ├── user-service/
  ├── notification-service/
  └── legacy-crm/

Each folder is a Schemity workspace containing plain JSON files. The entire repo lives as ~/schemity/ on every engineer's machine. Schemity opens it as a central hub.

Schemity does not stand in your workflow. It does not replace your migration tool. Your schema changes still flow through whatever your team already uses: Django, Rails, Flyway, Atlas, anything. Schemity sits alongside that workflow, not in front of it.

Here is what it looks like in practice:

For the engineer making the change: Clone company-erd-repo once into ~/schemity/. Run your migration as normal. Once it is applied to your local database, open Schemity, connect to it, and let it reflect the current state. Arrange the entities, update the relationships, add legends to give the diagram business meaning. Commit the updated JSON and open a PR against the ERD repo.

For the engineer reviewing the change: Pull the branch. Open Schemity. The diff is right there, a JSON file change that maps directly to a visual diagram. No migration file archaeology. No mental reconstruction of what the schema looked like before.

For the architect reviewing multiple services: One repo. One clone. Every service's schema in one place. No hopping between repos hoping someone committed a diagram.

For the new engineer onboarding:

git clone git@github.com:company/erd-repo.git ~/schemity

One command. Every service. Every relationship. Every constraint. The full picture of the company's data model, version-controlled and up to date.

What this unlocks that dbdiagram.io never can:

Schema changes get reviewed like code. When a schema change requires a PR against the ERD repo, the change gets reviewed before it is applied, not after. The history of every schema decision lives in Git: who changed it, when, and why.

The database is always the source of truth. Real teams miss steps. An engineer ships a migration in a busy sprint and forgets to update the ERD. It happens. With dbdiagram.io, that diagram is now wrong and nobody knows it. With Schemity, the next time anyone opens that ERD and connects to the database, Schemity reflects the current state automatically. The new tables are there. The new relationships are there. The new columns are there. The only thing missing is the visual arrangement: where the entities sit on the canvas and how the lines are routed. Drag a few boxes, tidy the lines, commit. No data lost. Nothing out of date. The diagram catches up in minutes, not sprint cycles.

This is separation of concerns applied to the full engineering stack. Source code in service repos. Infrastructure in the infra repo. Schema in the ERD repo.

It is not a feature dbdiagram.io can add. It would require rethinking what an ERD tool is for.

Pricing: One-Time vs. Monthly

dbdiagram.io: $9/month ($108/year) once you exceed the free tier.

Schemity: $129 one-time with $69/year renewal for updates (optional, the tool works forever without renewing).

At 14 months, Schemity costs the same as dbdiagram.io's subscription. Every month after that, Schemity is free. If you use it for three years (and engineers tend to stick with tools that work), Schemity costs $129 + $138 = $267 total. dbdiagram.io costs $324 for the same period, and you still don't own it.

The more important pricing difference is philosophical. Schemity's one-time model is a statement: the tool is valuable enough that you'll keep using it without being forced to. You don't stay because canceling is painful. You stay because the tool earns it.

Who Should Use dbdiagram.io

You need a diagram in the next five minutes for a meeting
You'll never look at this diagram again after today
You're communicating a schema idea, not building one
You think in DBML and the code-first interface is faster for you
The diagram doesn't need to live anywhere except a Slack link

dbdiagram.io is excellent for this use case. Use it without guilt.

Who Should Use Schemity

You need the diagram to still be accurate next month
Your ERD belongs in your repository, not in someone else's cloud
You work offline, behind a VPN, or in a restricted environment
You're graduating from a basic tool without wanting a tool that feels like an enterprise installation ceremony
You want to generate migrations directly from your design for a personal project or fast POC, without a full migration framework in the way
You're a senior engineer recommending a tool to a junior who shouldn't be defeated by the installer

The Bottom Line

dbdiagram.io is a sketch pad. It's a very good sketch pad.

Schemity is a design tool that happens to be as fast as a sketch pad.

The question is not which tool is better in absolute terms. The question is whether your ERD is a communication artifact that lives in a meeting, or a design artifact that lives in your codebase.

If it's the latter, Schemity was built for you.

If Schemity sounds like the right fit, you can grab it at schemity.com, 9 MB, 2-week full trial, no account required.