How to Choose a Database Design Tool 2026/2027

In short

Your enterprise modeler is up for renewal and only three people open it. Run four tests on a copy of your own schema, then compare the three-year cost. For schemas that span several engines and belong in Git, DbSchema is the database design tool to start with.

Key takeaways

• DbSchema keeps the whole design in one model file you commit to Git, and compares that model with a live database before any SQL runs.
• Count tables, views, foreign keys, enum types and triggers in the catalog first; the reverse-engineered model has to return the same numbers.
• Seed a staging copy with known drift, including a changed default and a new enum value, and count what each compare lists.
• A column that a view reads can only be changed by a migration that drops and recreates the view around the ALTER.
• Over three years, DbSchema Pro costs $444, DBeaver Enterprise $765 and Redgate Data Modeler Pro $909.

The decision criteria that matter

Five criteria separate design tools faster than a feature matrix does, and each one has a check you can run in an afternoon:

Weight them by your own estate. A single-engine shop meets engine coverage later than a mixed estate. A team that approves schema changes in a review board meets model storage later than one that approves them in a pull request. Compare and deploy has no later date, because that is the step where a design tool either stops a bad migration or runs one.

Platform and licence decide who can open the design at all, so read them off the vendor pages before the shortlist. ER/Studio Data Architect lists Windows 11 and 10 as its operating systems, and erwin Data Modeler 15.0 installs on Windows and macOS. Both start with a trial instead of a free edition, 14 days for ER/Studio and 15 days for erwin. ER/Studio's Git integration comes through Team Server Core at additional cost. These were read on the vendors' pages on 25 October 2026. A database design tool that fails your operating systems or your review workflow leaves part of the team out of the design.

How to test each one

Run the tests on a copy of a real schema, never on the vendor's sample, because the sample has none of the awkward parts. The examples below ran on PostgreSQL 16.14 on 25 October 2026, against a 14-table demo schema and a staging copy with 12 deliberate differences.

Test 1: count the catalog, then the model

Count what the database holds before you reverse-engineer it, so the model has something to be checked against:

SELECT 'tables' AS object_kind, count(*) AS n
FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public' AND c.relkind IN ('r', 'p')
UNION ALL
SELECT 'views', count(*)
FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public' AND c.relkind IN ('v', 'm')
UNION ALL
SELECT 'foreign keys', count(*)
FROM pg_constraint WHERE connamespace = 'public'::regnamespace AND contype = 'f'
UNION ALL
SELECT 'self-referencing foreign keys', count(*)
FROM pg_constraint WHERE connamespace = 'public'::regnamespace AND contype = 'f' AND conrelid = confrelid
UNION ALL
SELECT 'composite primary keys', count(*)
FROM pg_constraint WHERE connamespace = 'public'::regnamespace AND contype = 'p' AND array_length(conkey, 1) > 1
UNION ALL
SELECT 'enum types', count(*)
FROM pg_type WHERE typnamespace = 'public'::regnamespace AND typtype = 'e'
UNION ALL
SELECT 'triggers', count(*)
FROM pg_trigger t JOIN pg_class c ON c.oid = t.tgrelid
WHERE c.relnamespace = 'public'::regnamespace AND NOT t.tgisinternal;

Reverse-engineer the same schema into each candidate and count the same objects in its model. A self-referencing key that was dropped, or an enum type that came back as a plain text column, shows up as a gap. The pg_constraint catalog[1] documents the contype codes the query filters on, f for a foreign key and p for a primary key.

Test 2: seed the drift a compare has to find

Copy the schema to a second database and change the copy the way staging drifts away from development. The staging copy here carries 12 differences:

• a column that exists only in development
• a column added on staging by a hotfix
• a varchar(10) widened to varchar(20) on staging
• a foreign key dropped on staging
• an index that exists only on staging
• an index missing on staging
• a table that exists only on staging
• a table that exists only in development
• a changed column default
• a NOT NULL relaxed on staging
• an enum value added on staging
• a view whose definition changed

A diff of the column, constraint and index definitions between the two databases found 10 of the 12. The changed default and the added enum value only appeared with a second query, over the defaults in information_schema.columns[2] and the labels in pg_enum[3]:

SELECT table_name || '.' || column_name || ' DEFAULT ' || column_default
FROM [information_schema.columns](https://www.postgresql.org/docs/16/infoschema-columns.html)
WHERE table_schema = 'public'
  AND column_default IS NOT NULL
  AND column_default NOT LIKE 'nextval%'
UNION ALL
SELECT 'enum ' || t.typname || ': ' || string_agg(e.enumlabel, ', ' ORDER BY e.enumsortorder)
FROM pg_type t JOIN [pg_enum](https://www.postgresql.org/docs/16/catalog-pg-enum.html) e ON e.enumtypid = t.oid
GROUP BY t.typname
ORDER BY 1;

Run on both databases, these are the two lines that differ:

Neither change alters a column's type. Both change behavior: a new team gets a different plan on staging, and an insert of 'blocked' succeeds on staging and fails in development. Seed your test copy with both, run each candidate's compare between the two copies and count what it lists. Every difference it leaves out is one you would otherwise find after the deploy.

A compare worth buying puts each difference on its own row with both values side by side, and lets you decide per row which side changes. In DbSchema that is the synchronization dialog of Schema Synchronization, which works with DbSchema Pro.

Each difference gets its own row, with both values side by side and a per-row choice of which side changes (Schema Synchronization, DbSchema Pro).

Test 3: generate the migration and read it

Change a column type in the model, generate the migration, and read every statement before anything runs. Check the order, what happens to the data in the changed column, and what happens to the objects that depend on it. Widening a column directly fails in PostgreSQL 16 when a view reads it:

BEGIN;
ALTER TABLE projects ALTER COLUMN key TYPE varchar(20);
ROLLBACK;

ERROR:  cannot alter type of a column used by a view or rule
DETAIL:  rule _RETURN on view v_task_overview depends on column "key"

A usable migration drops v\_task\_overview, alters projects.key and creates the view again, in that order and in one script you can read. If a candidate's script stops at the ALTER TABLE, it fails the same way the statement above does. The guide on what to test in a schema compare tool goes further into this test.

Test 4: open the documentation on a machine without the modeler

Export the documentation and open it on a machine with none of the tooling installed. The demo schema carries three column comments, so the check is concrete: all three have to appear next to their columns. The diagram has to be readable without a viewer plug-in.

What the cost is over three years

The licence shape decides the three-year number more than any year-one discount. A perpetual licence keeps working whether or not you renew, and the renewal buys new versions. A subscription charges the same in year three as in year one.

All prices are per user, in US dollars, before taxes, read on each vendor's own page on 25 October 2026. The DbSchema figures are the Business tab of the purchase page. Idera gives the ER/Studio figure as a total subscription price per user and refers multi-year discounts to its sales team, so that cell stays empty rather than guessed.

Three-year cost per user before taxes: a perpetual licence with two update renewals against three years of subscription, prices read on the vendors' pages on 25 October 2026.

A team that shares seats instead of naming users can buy DbSchema Architect as a floating licence, at $1,168 plus $280 a year for updates. Simultaneous users are limited to the seats bought. The guide to which database tool edition a team needs covers sizing the edition.

The questions to ask a vendor

Take these five to the call. Each answer changes either the three-year cost or the security review, and none of them appears in a feature matrix.

1. Does team work on one model need a server of yours, or is the model a file we version in our own Git repository?
2. Which engines and drivers are in the base licence, and which are paid add-ons?
3. Does the software run with no outbound connection, and how is a licence activated on such a machine?
4. What does the documentation export produce, and can a colleague read it without installing your client?
5. What does the compare check before it executes, and how does it handle a change that a dependent view blocks?

The same answers settle most of the security questions about a schema sync tool that a reviewer raises later.

DbSchema answers the first question with a file. It saves the design, tables, foreign keys and diagrams, in one .dbs model file, and Git Collaboration commits, pulls and pushes it from inside DbSchema. Git changes only the model file, never the database. The model file for the demo schema is 574 lines of XML with 14 table, 23 foreign key and 2 view elements, the same counts the catalog query returned. A reviewer can check test 1 against the file itself.

For the fifth question, DbSchema's Schema Synchronization lists every difference between the model and the database, writes the SQL for the database side and shows it before it runs. Offline, your changes stay in the model and the database doesn't change until you connect again and decide. For the fourth, DbSchema's Schema Documentation writes HTML5 with the diagram as a vector image and the comments as mouse-over tooltips, or a PDF or Markdown file. For the third, the licensing page lists three ways to register DbSchema: an account, a licence key, or a seat leased from a license server on your own network.

Download DbSchema, connect it to a copy of your own schema, and run the four tests before the decision meeting. Connecting, reverse-engineering, the interactive diagrams and the SQL editor are in the free Community Edition. Saving the model to a file, Schema Synchronization and the HTML5 documentation are in DbSchema Pro, and logical and conceptual design is in DbSchema Architect.

Sources

1. postgresql.org
2. postgresql.org
3. postgresql.org