Most database tools treat schema design as a chore to be endured. What if the tool got out of the way - and let the thinking take center stage?
There is a specific kind of friction that accumulates when your tools don’t think the way you do. You’re modeling a domain - orders, customers, inventory - and instead of thinking about the domain, you’re fighting the diagram. Lines route themselves into knots. The interface demands clicks where you wanted drag. You rename a table and half the diagram forgets about it.
This is the silent tax of bad tooling. And in database design, it compounds: every minute fighting the diagram is a minute not spent questioning the model itself.
The diagram is the model
Before we talk about joy, we need to talk about what an ERD actually is. Not the artifact - the act. When you lay out entities on a canvas and draw the relationships between them, you are making architectural decisions. The spatial arrangement is an argument: these things belong together, these things are separate, this boundary is real.
A tool that forces you to fight the layout is a tool that argues against your thinking. A tool that flows - that routes lines intelligently, that auto-names foreign keys, that treats relationships as first-class objects you can create by drag - is a tool that amplifies your thinking.
The best database tools don’t ask you to describe your model. They ask you to draw it - and then they make the description for you.
What “opinionated defaults” actually means
Schemity is unapologetically opinionated. It defaults to snake_case naming, auto-generates foreign key names, and creates junction tables for many-to-many relationships without asking. To some, this sounds constraining. In practice, it is liberating.
Convention is what lets you stop thinking about convention. When the tool handles the mechanical parts - naming, routing, constraint placement - your attention stays on the structural questions: Should this be a separate entity? Does this relationship imply a domain boundary? Is this constraint expressing a business rule or a workaround?
That’s where the joy lives. Not in naming foreign keys.
Color as communication
One of the subtler joys in Schemity is color. Not theme color - entity color. You can assign colors to entities and their relationship lines inherit that color. On a large schema, this is the difference between a diagram you can read and a diagram you have to decode.
When all the order-management tables are one color and all the inventory tables are another, the domain boundaries become visible without a legend. The spatial argument of the diagram gets reinforced by its chromatic argument. You start to see the schema as a territory, not a list.
Arrange freely, read clearly
Most ERD tools impose a layout on you. Auto-arrange, force-direct, snap-to-grid. The result is a diagram that is geometrically tidy and semantically meaningless - entities cluster by algorithm, not by domain logic.
Schemity takes the opposite position: you arrange freely, and the tool makes that arrangement look intentional.
There are no layout constraints on where you place entities. You can put the order table at the center of the canvas because it is the center of the domain. You can cluster address, contact, and customer in the top-left because they form a conceptual unit. You can leave deliberate whitespace between bounded contexts to make the boundary visible. The diagram encodes your understanding, not the tool’s preference.
Arrange your diagram the way you think about it, not the way the layout forces you.
What makes this work without descending into visual chaos is Schemity’s relationship routing. When a relation line has three points - source, one waypoint, and target - it enforces orthogonal exit from its source entity. The line leaves the table at a right angle before turning toward its destination. This single constraint does a surprising amount of work: it eliminates the diagonal spaghetti that plagues freely-arranged diagrams, keeps the canvas readable at any scale, and gives even complex schemas a sense of deliberate structure.
You get the freedom of manual arrangement with the visual discipline of a structured layout. Add a custom waypoint anywhere to route a line around an obstacle. Double-click to remove it when you no longer need it. The line adapts, re-routes, and stays clean. The result is a diagram that looks like you intended every line - because the tool helped you intend it.
The migration is the proof
There is a moment in every database project where the design meets reality. You’ve drawn the schema, the team has reviewed it, and now it has to become SQL. In most tools, this moment is where friction returns with force: you write migrations by hand, cross-referencing the diagram, hoping you haven’t missed a constraint.
Schemity closes this gap. It compares your ERD to the live database and generates the exact SQL diff - nothing more, nothing less. Every schema change requires explicit migration confirmation. The tool treats the diagram as the source of truth and makes the database conform to it.
This is the real payoff of designing visually. The diagram isn’t documentation of what you built. It is what you built. The SQL is derivative.
Offline, native, 9 MB
There’s a quiet joy in software that simply starts. No loading spinner for a remote workspace, no cloud account to authenticate, no Electron runtime to bootstrap. Schemity is built with Rust and a native WebView - the whole application is 9 MB and launches instantly.
It works offline, behind a VPN, air-gapped. Your ERD files live in ~/schemity/ as plain JSON - readable, backupable, portable. You own them completely. This is not a feature; it’s a philosophy. Tools that respect your ownership are tools you trust.
Design like you think
Joy in tool use is not about delight mechanics or gamification. It’s simpler and harder: the tool disappears. You stop noticing it because it is no longer in your way. Your attention fills completely with the problem - the domain, the boundaries, the rules that need encoding.
That’s what good ERD design feels like when the tool earns it. You’re not drawing a diagram. You’re thinking about your system, and the diagram is how the thinking becomes visible.
Schemity is built for that moment.
