Visual query builder

It builds a SELECT by dragging rather than typing, and shows you the SQL as it goes. There are three ways in:

• Right-click a database in the sidebar and choose Visual Query Builder.
• Query Builder in the main toolbar, next to the profiler — it opens on the connection and database you are already working in.
• Query Builder in the SQL editor toolbar — the same, except it loads the SQL that is already in the editor onto the canvas.

Building a query

1. Add tables — click ＋ next to a table to put it on the canvas.
2. Join them — drag from a column in one table to a column in another. NabuSQL adds the join condition.
3. Pick the join type — each join is labelled and can be INNER, LEFT, RIGHT or FULL.
4. Choose columns — tick the columns you want in the result.
5. Filter — add WHERE conditions with the operators =, !=, >, <, >=, <=, LIKE, IS NULL, IS NOT NULL, IN.
6. Group and order — set GROUP BY and ORDER BY columns.

The generated SQL updates as you work.

Choosing what it runs against

The connection and database pickers sit on the right of the builder toolbar, so you can point the builder somewhere else without closing it. Tables belong to one database, so switching either picker empties the canvas — NabuSQL asks first when there is something to lose.

The builder keeps its state when you switch to another tab and back: the canvas layout, joins, conditions and any results you ran are all still there.

Saving the query

Save Query asks for a name and stores the result like any other query: it shows up in the sidebar under the connection → database → Queries, where you can open, run and edit it. Saving under a name that already exists on the same connection and database updates that query instead of creating a second one.

If the connection has a Queries folder configured, the query is written there as a .sql file as well — see Moving connections and queries. The file is written first: if that fails, nothing is saved and you get the error rather than a false confirmation.

Once saved, the tab takes the query's name and the next save offers that name again.

Opening existing SQL in the builder

The Query Builder button in the SQL editor sends the editor's text — or just the selection, if you have one — into a new builder tab, and the builder reads it back into tables, joins, columns, conditions, grouping and ordering. Table aliases are resolved to the tables they stand for.

It understands the same subset it writes: a single SELECT with joins, WHERE, GROUP BY, ORDER BY and a row limit. Anything beyond that — subqueries, calculated columns and function calls, HAVING, UNION, NOT IN / NOT LIKE, join conditions with more than one comparison, OFFSET — is left out and named in a warning bar above the canvas, so what you see is never quietly a different query from the one you started with. If nothing can be read at all, you get a message instead, and the SQL is untouched in the editor tab you came from.

The SQL it writes

Identifiers are quoted the way your server expects: backticks for MySQL and MariaDB, double quotes for PostgreSQL and SQLite, square brackets for SQL Server. Schema-qualified names are quoted part by part, so dbo.accessory becomes [dbo].[accessory].

Row limits follow the same rule — SQL Server gets SELECT TOP n, everything else LIMIT n.

Values in conditions are escaped, so an apostrophe in O'Brien doubles up instead of breaking the query. Numeric columns are compared against unquoted numbers, which PostgreSQL insists on. In an IN condition you type a comma-separated list; anything you quote yourself is kept as you typed it.

Using the result

The ▶ button runs the query and shows the rows below the canvas. To take it further, copy it into a SQL editor tab to tune it, or paste it into a view definition — see Views.

What it is good for

The builder is at its best when you are exploring a schema you do not know well: you can see which columns join to which, and get a correct multi-table SELECT without looking up every foreign key by hand.

It generates plain, readable SQL — there is no proprietary format to get locked into, and nothing stops you from editing the result by hand afterwards.

Limits

It builds SELECT statements. Subqueries, window functions, UNION, CTEs, INSERT/UPDATE/ DELETE and anything engine-specific belong in the SQL editor. FULL JOIN is offered, but MySQL and MariaDB do not support it — the server will reject that query, not NabuSQL.

If you would rather describe the query in words than draw it, the AI assistant is the other route to the same place.