Frequently asked questions

Paste the query into SQLExplain and it will parse the SQL, then describe it in plain business language: which tables it starts with, which rows are kept or filtered out, what's being summed, averaged, or counted, how the data is grouped, and what a single row of the final result represents.

You don't need to trace every join by eye. SQLExplain reads the query the way a parser does, builds a structural map of it, and turns that map into a step-by-step explanation, plus a diagram showing how the data moves through the query from source tables to final output.

SQLExplain looks at the join type and the relationship between the joined tables and flags where a join is likely to multiply rows, for example a one-to-many join feeding into a SUM before any deduplication happens. It calls this out directly rather than leaving it for you to notice after the numbers look wrong.

Often a metric "looks wrong" because a filter excluded more rows than expected, a join dropped unmatched records, or an aggregation ran at a different grain than assumed. SQLExplain's field trace walks a specific output column backwards through every filter, join, and calculation that shaped it, so you can see exactly where the number diverges from what you expected.

SQL lineage is the path a piece of data takes from its original source column, through every transformation, join, and calculation, to a field in a final result. SQLExplain builds this lineage automatically and lets you trace any output field backwards to see where it actually came from.

Before any SQL reaches an AI model, SQLExplain replaces database names, schema names, table names, and hard-coded literal values (numbers, dates, and text) with neutral placeholder tokens. Column names are kept because they carry the meaning needed for a useful explanation. The AI never sees your real table names, your real literal values, or the data stored in your tables. You can review exactly what would be sent before it happens.

SQLExplain is built on a general-purpose SQL parser and supports common dialects including Snowflake, BigQuery, PostgreSQL, MySQL, SQL Server (T-SQL), Redshift, and Databricks/Spark SQL. Dialect is detected automatically where possible, and you can select it manually if detection is uncertain.

A few constructs are detected but not yet fully traced end to end: UPDATE, DELETE, and MERGE statements, stored procedures and procedure calls, triggers, dynamic SQL, and some advanced window-function patterns. Where SQLExplain hits one of these, it says so directly in the explanation instead of guessing at what the logic does.

No. SQLExplain only asks for column and table structure (metadata), never the rows or records stored in your tables, and only when it genuinely needs that structure to resolve something like a SELECT * or an ambiguous column reference. It tells you exactly which tables it needs structure for and why.

Yes. You can upload a set of related SQL files and SQLExplain will map how they connect, from raw source tables through intermediate views and CTEs to your final reporting tables, so you can see the whole pipeline in one place.

No. SQLExplain only parses and analyzes the text of your SQL. It never connects to your database and never executes your query, so it has no way to see or return your actual data.

Business analysts, product managers, finance and operations professionals, and junior data analysts who can read some SQL but want confidence in what a query actually does, and what it might get wrong, before trusting the number it produces.