SQL Query Visualizer

About the SQL Query Visualizer

The SQL Query Visualizer parses SQL SELECT statements and renders a visual diagram of the query structure — tables, JOIN relationships, filter conditions, and output columns. Use it to understand unfamiliar queries, explain query logic to non-technical stakeholders, review query plans before optimisation, and document database schemas.

How to Use

• Paste a SQL SELECT query into the input field. The visualizer supports MySQL, PostgreSQL, and standard SQL syntax.
• Click Visualize. The tool parses the query and renders a diagram showing each table as a node, JOIN conditions as edges, WHERE clause filters, and the SELECT output column list.
• Hover over nodes and edges to see the full condition text.
• Use the output to verify join directions, identify missing join conditions, spot Cartesian products, and review column aliasing.

What the Visualizer Shows

• Tables and aliases — Each FROM clause table and subquery appears as a named node. Table aliases are shown alongside the full table name.
• JOIN relationships — INNER JOIN, LEFT JOIN, RIGHT JOIN, and FULL OUTER JOIN are drawn as directed edges with the join type labelled. The ON condition is shown on the edge.
• WHERE clause filters — Filter predicates are listed separately from join conditions, showing which tables and columns are constrained.
• SELECT columns — Output columns are listed with any expressions, aggregates, or aliases applied.
• Subqueries — Inline views and correlated subqueries are represented as nested nodes within the diagram.

JOIN Types Explained

• INNER JOIN — Returns only rows where the join condition is satisfied in both tables. Rows without a match on either side are excluded.
• LEFT JOIN (LEFT OUTER JOIN) — Returns all rows from the left table and matched rows from the right table. Unmatched right-side rows return NULL. The most common join type in reporting queries.
• RIGHT JOIN (RIGHT OUTER JOIN) — Returns all rows from the right table and matched rows from the left. Equivalent to reversing the table order in a LEFT JOIN.
• FULL OUTER JOIN — Returns all rows from both tables, with NULLs where there is no match on either side. Not supported in MySQL; use UNION of LEFT and RIGHT JOINs instead.
• CROSS JOIN — Produces the Cartesian product of both tables — every combination of rows. Rarely intentional; a missing JOIN condition in some dialects silently produces a CROSS JOIN.

Common Query Structure Issues

• Implicit cross joins — Listing two tables in FROM without a JOIN condition (FROM orders, customers) produces a Cartesian product. The visualizer highlights tables with no join edge as a warning.
• Ambiguous column references — When multiple tables have a column with the same name, referencing it without a table qualifier is ambiguous. Explicit table or alias prefixes (orders.status vs o.status) eliminate ambiguity.
• Filters in ON vs WHERE — Placing a filter condition in the ON clause of a LEFT JOIN keeps unmatched rows (with NULL for filter columns). Moving the same condition to WHERE eliminates unmatched rows, converting the LEFT JOIN to an effective INNER JOIN. The visualizer separates ON and WHERE conditions for clarity.
• Aggregate without GROUP BY — Using aggregate functions (COUNT, SUM, AVG) without a GROUP BY collapses the entire result to one row. Adding GROUP BY with the appropriate non-aggregate columns restores row-level aggregation.

Frequently Asked Questions

Does the visualizer execute the query against a database?

No. The visualizer parses the SQL text and analyses the query structure without connecting to any database. Your query is processed entirely in the browser. No table data or schema is required — the diagram is based on the query syntax alone.

Can it visualize stored procedures or complex DDL?

The visualizer is designed for SELECT queries. It parses FROM, JOIN, WHERE, GROUP BY, HAVING, and SELECT clauses. Stored procedures, triggers, and DDL statements (CREATE TABLE, ALTER) are outside the visualizer's scope.

How do I read a query with many JOINs?

Start from the central fact table (usually the largest table, often the first in the FROM clause) and trace each JOIN edge. LEFT JOINs indicate optional relationships — the left table can exist without a matching row in the joined table. Follow the WHERE conditions to understand which rows are filtered after joining. The visualizer's node-and-edge layout makes this path tracing faster than reading raw SQL.

What is the difference between ON and USING in a JOIN?

ON table1.id = table2.fk_id is the general form — it can join on any condition. USING (column_name) is shorthand for joining on a column with the same name in both tables (ON t1.id = t2.id). USING also deduplicates the join column in the output (it appears once, not twice). Both are fully supported in the visualizer.

Can I use this to understand a query generated by an ORM?

Yes. ORM-generated queries (Laravel Eloquent, Hibernate, SQLAlchemy, ActiveRecord) are often verbose with many JOINs and aliases. Pasting the raw SQL output from query logging into the visualizer is one of the fastest ways to understand what the ORM is actually doing at the database level.