How to Build a SELECT Query Visually: A SQL Builder Guide

You need a query that joins three tables, groups the result, and filters on a date range, but the only thing you remember about SQL today is that SELECT goes first. Typing the query from scratch means juggling keywords, parentheses, and the right clause order in your head at the same time. A SQL Builder lets you skip that part: you stack the clauses you need as blocks, and the tool assembles them into valid SQL in the right order.

You can try every example below in the SQL Builder — it runs entirely in your browser, so even production schemas never leave your machine.

From blocks to a finished query

Here's what you usually have in your head when you start writing a query:

"I want user names and their order totals for paid orders since January, sorted by total, only the top 20."

Staring at an empty editor, that turns into a wall of keywords. With a builder, you describe the same idea as a stack of blocks:

• SELECT — users.name, SUM(orders.total) AS total_spent
• FROM — users
• JOIN — orders ON users.id = orders.user_id
• WHERE — orders.status = 'paid' AND orders.created_at >= '2026-01-01'
• GROUP BY — users.id, users.name
• ORDER BY — total_spent DESC
• LIMIT — 20

The builder stitches those blocks into a finished query you can copy and run:

SELECT
  users.name,
  SUM(orders.total) AS total_spent
FROM
  users
  JOIN orders ON users.id = orders.user_id
WHERE
  orders.status = 'paid'
  AND orders.created_at >= '2026-01-01'
GROUP BY
  users.id,
  users.name
ORDER BY
  total_spent DESC
LIMIT
  20

Same result, no mental juggling.

Step 1: Add the SELECT block

Every query starts with the columns you want back. Add a SELECT block and start typing column names or expressions. Use Add column for each new field. The builder keeps the list comma-separated and on separate lines so the output stays readable.

For aggregations like SUM, COUNT, AVG, just type the function call directly — the builder doesn't try to be smarter than your SQL and will pass it through verbatim.

Step 2: Choose FROM and JOIN

Pick a base table in the FROM block. If the query needs more than one table, click Add JOIN and pick the join type — INNER, LEFT, RIGHT, or FULL. Set the alias for each table and fill in the ON condition.

This is also where most SQL mistakes happen in real life: an ambiguous column reference, a forgotten join condition, a Cartesian product. Seeing the JOIN as its own block with its own ON line makes it harder to forget the predicate or to accidentally join twice on the same key.

Step 3: Add WHERE conditions

The WHERE block is a list of predicates joined by AND or OR. Add a condition, choose the operator (=, !=, >, IN, LIKE, BETWEEN, IS NULL), and the builder formats them on separate lines so each condition is easy to comment out during debugging:

WHERE
  orders.status = 'paid'
  AND orders.created_at >= '2026-01-01'
  AND users.country IN ('US', 'CA', 'MX')

Notice how the boolean operator leads the line — that's the same convention the SQL Formatter uses, so the query you build here is formatted the same way as a query you'd clean up by hand.

Step 4: GROUP BY, HAVING and ORDER BY

Once you have aggregates in the SELECT list, GROUP BY is mandatory — every non-aggregate column in SELECT must appear in GROUP BY. The builder keeps that contract visible by listing the GROUP BY block right after WHERE and before ORDER BY.

If you need to filter after aggregation (for example, "only show customers who spent more than $500"), add a HAVING block. ORDER BY comes last, with ASC or DESC per column. LIMIT closes the query.

Canonical clause order, automatically

A real source of bugs is putting clauses in the wrong order — for example, writing WHERE after GROUP BY, or LIMIT before ORDER BY. SQL doesn't have to accept that, but it sometimes will, and the result is hard to predict.

The builder fixes this for you: regardless of the order you add the blocks in the UI, the rendered output is always in the canonical order:

SELECT → FROM → JOIN → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT

Add ORDER BY first by accident? It still ends up last in the generated SQL. This is one of the quietest benefits of building the query visually instead of typing it — the tool enforces the grammar, so you can focus on the what and not the where does this clause go.

Reading the generated SQL

Once the query looks right, click Copy to grab the SQL. The output is clean, formatted, and dialect-aware: choose PostgreSQL, MySQL, SQL Server, SQLite or Standard and the identifier quoting, string escaping and function names match what your database actually expects. Paste it into your SQL client or your ORM and it runs as-is.

If you want to keep iterating on it as plain SQL — adding a CASE expression or a window function the builder doesn't expose — paste the output into the SQL Formatter for further cleanup, or compare it against a previous version with SQL Compare.

Everything stays in your browser

The builder runs 100% client-side. No query, table name, or schema ever leaves your browser, so it's safe to assemble queries against real production schemas.

Next: format and compare

Building the query gets you a clean, valid SELECT. Once you have it, two companion tools finish the loop. Read How to Format SQL: A Complete Guide for tidying any query you write by hand, or How to Compare Two SQL Queries to see what changed between two versions of the same report.