You are fifty minutes into modeling an ordering flow. Customers, orders, order items, payments, refunds - the shape is finally coming together, and you drag out one more entity for shipment tracking. The tool refuses. Not because anything is wrong with your model, but because you have reached the plan limit.

This is not a rare edge case; it is the business model of most browser-based diagram tools. On Lucidchart’s free plan you get 60 objects per document - and lines and text boxes each count as an object, so a modest schema with labeled relationships hits the wall long before 60 tables; users show up on the community forum confused about why they cannot add a shape to a diagram that looks half-empty. DrawSQL’s free plan caps you at 15 tables, and every diagram on it is public - privacy itself is the paid feature. dbdiagram.io meters along the same lines, which is part of why people go looking for a dbdiagram.io alternative once a side project grows real.

Fifteen tables is not a database. It is a demo of a database. Any system that earns its keep - a store, a booking engine, a multi-tenant SaaS - blows past fifteen tables while it is still a sketch.

The pricing page ends up inside your data model

The obvious cost of a table limit is the interruption. The insidious cost is what you do to stay under it.

You merge two entities that should be separate, because separate would cost a table. You leave the junction table out of the diagram and keep it “in your head.” You split one coherent domain across three free-tier diagrams that cannot see each other, then hold the joins between them in memory. You stop labeling relationships because every label spends an object from the same budget as your tables.

Every one of those is a modeling decision, and none of them came from the domain. They came from the pricing page. A database design tool is supposed to be where you think clearly about structure; a metered canvas quietly optimizes your schema for the vendor’s upgrade funnel instead. And the meter always runs out at the worst moment - not when you are evaluating tools with a cold head, but mid-thought, with the model half-formed, when re-drawing everything somewhere else feels more expensive than pulling out a credit card.

There is a name for that feeling: the tool has your work hostage. It is the same structural problem as a diagram that can vanish from a vendor’s list, showing a different face. Your model lives inside someone’s quota system, and the quota is designed to be hit.

Files do not have quotas

Schemity is a desktop ERD tool, and its answer to plan limits is the same boring answer it gives to durability: your diagram is a file on your disk. A workspace is a folder of plain JSON files, and there is no meter that a file on your own machine could possibly report to.

The status bar in that screenshot is the whole philosophy in one line. Entities: 54, Relations: 80 - a perfectly ordinary CMS schema, and by Lucidchart’s accounting those 134 objects are more than two full free plans spent before the first label. By DrawSQL’s, it is three and a half upgrades. Schemity prints the same numbers where a metered tool would print a warning: in the footer, as information, next to the PostgreSQL version. Fifty-four entities is not an achievement the tool congratulates you on or a threshold it charges you for. It is Tuesday.

So the limits are the ones physics gives you, not the ones a tier gives you:

• Tables are not counted. An entity is a few kilobytes of JSON. Model fifteen tables or four hundred; the local ERD tool treats them identically, and entities auto-size and stay keyboard-movable either way.
• Diagrams are not counted. A workspace holds as many connections and diagrams as your work needs, open side by side in tabs. You split diagrams because the domain has seams, not because a plan does.
• Workspaces are not counted. Keep one per client, one per product, one for the book you are writing. This matters most for client work, where each engagement needs its own cleanly separable folder.
• Views are not counted. When a big model needs a focused slice - just billing, just identity - you create context views, as many as you need, without spending anything from any budget.

Notice what disappears along with the meter: the perverse incentives. Nothing nudges you to under-model. A lightweight ERD tool that stores everything as local files has no reason to care how big your schema is, so the only thing shaping your model is your domain.

Private should not be a paid feature

The DrawSQL free tier makes a second trade explicit: below the paywall, your diagrams are public. Read that as a database designer for a moment. A schema is a map of how a business actually works - what it tracks, what it charges for, where the bodies are buried in deleted_at columns. Publishing it as the price of a free tier is a strange default, and for anyone doing NDA-bound work it is a non-starter.

An offline ERD tool inverts the default. Schemity’s files never leave your machine unless you move them, so privacy is not a feature to unlock - it is the absence of the machinery that made privacy a question. There is no public URL because there is no server. For a schema you genuinely want to share, sharing is a deliberate act: commit the JSON to a private repo and let Git carry the history, the way teams that keep the ERD in the repo next to the code already do.

Pay once, then stop thinking about it

The subscription-tier model has one more cost: it never stops asking. Every month the plan renews, and every limit is a renegotiation - more tables, more diagrams, more seats, another line on the invoice for a tool you think about twice a year.

Schemity is a one-time purchase ERD tool: $129, yours, done. An ERD tool without subscription cannot hold your table count hostage, because there is no recurring decision left to influence. The full feature set - reverse engineering, migration diffs, context views, the whole canvas - is simply what you bought, at any schema size, forever.

If a limit dialog is what sent you searching for a Lucidchart ERD alternative or a DrawSQL alternative, the fix is not a bigger tier. It is moving your model somewhere that structurally cannot meter it. Your schema should be exactly as large as your system demands - and the only party with an opinion about that should be you.