Enterprise Requirements for a Visual Query Builder

Your backend teams run PostgreSQL, a Snowflake warehouse for reporting and a MongoDB service nobody has documented, and each engineer opens a different client for it. DbSchema is the one to standardize on: it reverse-engineers all of them into diagrams, assembles the joins with the mouse in its Query Builder, and shows the SQL it wrote before anything runs.

DBeaver, JetBrains DataGrip and Navicat Premium turn up on the same shortlist. The requirements below are the ones worth testing against your own schemas before the purchase order goes out.

What a query builder has to do that a SQL console does not

A SQL console answers a question you already know how to ask. On a schema of several hundred tables, the slow part is finding which tables hold the answer and how they join, and that is the part a visual builder takes over from you.

The DbSchema Query Builder starts from the diagram. Click a table header and the builder opens loaded with that table, or choose New Query Builder from the Editors menu and drag tables into an empty one. Click the small arrow icon next to a column to follow a foreign key and add the related table. Click the join type label on the connecting line to switch the join between INNER JOIN, LEFT JOIN and EXISTS. Tick the columns you want in the SELECT list. Right-click a column and choose Filter to put a WHERE condition on it. Switch on Group By mode to turn the ticked columns into GROUP BY columns and apply MIN, MAX, SUM, AVG or COUNT to the rest. The generated SQL sits at the bottom of the builder and is rewritten as you click.

Where the database declares no foreign key, drag one column onto another in the diagram. DbSchema stores that virtual foreign key in the model file and the Query Builder follows it exactly as it follows a real one, so the join is available without an ALTER TABLE on a production schema.

Only the SELECT you run reaches the database. The builder itself, the virtual foreign keys and the diagram layout are saved in the .dbs model file, which is plain XML that Git treats like any other file in the repository. Working disconnected sends no statements at all: the changes go to the model file, and you review them against the database when you reconnect. The Query Builder and saving the model to a file are Pro features.

The other requirement worth writing into the evaluation is reach. DbSchema connects to 70+ SQL and NoSQL databases over JDBC and downloads the driver for each one when you create the connection, so a team that adds an engine does not also add a client.

Which of the four SQL statement types you build with the mouse

SQL statements fall into four groups, and a visual builder is not aimed at all four:

The DbSchema Query Builder covers the first row: it constructs SELECT queries, including the aggregates and the GROUP BY clause. The third row is diagram work. Edit a table on the diagram, then open Schema → Synchronize Model with Database to read the generated DDL and click Execute to apply it, which is the one moment the live database changes. The second row belongs to the Relational Data Editor, where Insert, Edit and Delete act on rows and nothing is written until you click Commit. Rollback discards the pending changes instead.

That split matters for an analyst who has read access and no more. Assembling a SELECT across eight tables, running it, and saving the result set to a file from the result pane never needs a permission beyond the one they already have.

Reaching cloud warehouses and NoSQL stores from the same client

Reporting data ends up somewhere other than the transactional database, and the two speak different dialects. Google BigQuery runs GoogleSQL, an ANSI-compliant dialect covering query, procedural, DDL, DML and DCL statements, with a legacy SQL dialect still available with limitations for older projects[1]. Snowflake is shaped differently again: virtual warehouses are independent compute clusters, and a central storage layer divides table data into micro-partitions and holds structured, semi-structured and unstructured data, including Apache Iceberg tables[2].

DbSchema reaches both over the same JDBC connection dialog it uses for PostgreSQL, so the warehouse appears as one more diagram beside the transactional schemas rather than as a browser tab in the Google Cloud Console or in Snowsight. The columns you tick in the Query Builder are the columns in the SELECT list, which is the projection the warehouse is asked to scan.

Four database models on one diagram

An enterprise fleet usually holds four kinds of store: relational engines such as PostgreSQL and Oracle, document stores such as MongoDB, key-value caches such as Redis, and graph or columnar engines. The document stores are the ones a diagram has to work for without a declared schema.

DbSchema introspects a configurable sample of documents per collection and infers field names, BSON types, nested objects and arrays, so what you see is an approximation of what the documents contain rather than a structure MongoDB enforces. Where a collection carries a $jsonSchema validator, MongoDB itself declares the required fields and their BSON types[3], and DbSchema reverse-engineers that rule as the authoritative structure instead of the sample. Creating or editing a collection in DbSchema writes the validation rule back to the database and to the model file alike.

Collections are then linked the same way tables are. Drag one field onto another and DbSchema draws a connector line and saves the virtual relation in the model file, without MongoDB declaring or enforcing anything. The Relational Data Editor opens several collections side by side over those relations: select a record in the parent and every child pane refilters to the documents whose field values match, cascading as many levels as you need. The exported HTML5 documentation carries a vector diagram of the result, with collection and field comments readable as mouse-over tooltips. Relational data browse, the documentation export and the data tools are Pro features.

The shortlist and what each tool is built around

DbSchema builds the query on a diagram it reverse-engineered, keeps the design and the builders in one file, and generates the migration script from the difference between that file and the database. That is the combination to check first if the design has to outlive the connection.

DBeaver's edition comparison lists a visual query builder and ER diagrams from the Lite edition upward, and schema editing on the diagram, the row it calls ERD Edit mode, from the Enterprise edition upward[4]. JetBrains DataGrip is a database IDE, so the query console and the code editing around it are where its work happens. JetBrains gives DataGrip a free 30-day trial and makes it free for non-commercial use[8]. Navicat Premium connects to several engines at once and moves data between them, and Navicat sells it monthly, yearly or as a perpetual licence[5].

The three questions to settle before you buy

The first is what happens to the licence when the renewal is skipped. DbSchema Pro is 294.00 USD once plus taxes on the Business tab of the pricing page, with the first year of updates and support included and 75.00 USD a year afterwards to keep receiving them; the monthly subscription on that tab is 29.40 USD. The Architect edition, which adds logical and conceptual design, is 470.40 USD once on the same Business tab, with 120.00 USD a year to renew. The page also has a Personal tab and a Universities and Students tab, each with lower figures, so read the tab that applies to you, and it prices in the visitor's currency, so the amount it shows you may not be the one quoted here[6].

The second is engine coverage on the day someone adds an engine, which is a question about drivers rather than about features: DbSchema downloads the JDBC driver for a new connection itself, and takes an uploaded driver .jar where downloads are blocked.

The third is whether the schema can be reviewed before it ships. A design that exists only as a live connection cannot go through a pull request. A .dbs file can, and DbSchema compares it against the target database and writes the migration SQL from the difference.

Download DbSchema at https://dbschema.com/download.html, connect it to the database your team argues about most, and build one report query on the reverse-engineered diagram. Connecting, reverse-engineering, the diagrams and the SQL editor are in the free Community Edition; the Query Builder, relational data browse, saving the model to a file, schema synchronization and the HTML5 documentation are Pro; logical and conceptual design is Architect.

Frequently asked questions

How does Navicat Premium's price compare with DbSchema Pro?

On the Enterprise tab of its price plan, Navicat lists Navicat Premium at USD 79.99 a month, USD 799.99 a year, or USD 1,599.00 for a perpetual licence, with a separate tab for non-commercial use[5]. Set those against the DbSchema Pro figures in the section above, which are a single payment plus an optional yearly renewal rather than a subscription.

What does DBeaver cost for an organization?

DBeaver sells its desktop editions as annual subscriptions covering usage, updates and support: Lite at 113 USD, Enterprise at 255 USD and Ultimate at 510 USD per licence per year[7]. The Community edition stays free.

Why keep the query builder in a file instead of a cloud console?

A DbSchema Query Builder is stored in the .dbs model file and reopens from the Editors menu with the model, so the query travels through Git with the schema it was written against. When you close one, DbSchema asks whether to keep it in the design model or drop it permanently.

Sources

1. cloud.google.com
2. docs.snowflake.com
3. mongodb.com
4. dbeaver.com
5. navicat.com
6. dbschema.com
7. dbeaver.com
8. jetbrains.com