Uppercasing is not formatting
Most SQL formatters do one thing: capitalise reserved words. A query that arrives as 380 characters on a single line goes back as 380 characters on a single line, now shouting. The keywords are easier to spot, but the structure — which tables are joined, which conditions belong to the join and which to the filter — is exactly as hidden as before.
Readability comes from where the lines break. Clause keywords are the joints of a statement, and a reviewer reads them down the left margin first — SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY — to work out the shape before reading a single expression. This tool breaks on those keywords and aligns them in one column.
Join conditions get the same treatment. Each JOIN starts a line with its ON condition attached, so a five-table query reads as five entries rather than one paragraph. When a condition is quietly sitting in the WHERE clause instead of the ON, which is the usual cause of an accidental cross join, it becomes visible immediately.
Where a subquery starts and stops
The hard part of reading unfamiliar SQL is knowing which SELECT you are currently inside. A derived table in FROM, a scalar subquery in the select list and an EXISTS in WHERE all look identical when every line sits at the same indentation, and counting brackets is a poor substitute for seeing the nesting.
Say you are pulling customers whose orders total more than ₹50,000 this financial year. The inner SELECT SUM(amount) FROM orders is indented one level, with its own FROM and WHERE lines in a column of their own, and the closing bracket returns to the outer margin. Depth is tracked as the query is parsed, so a subquery inside a subquery goes in two levels.
Common table expressions are handled the same way: each WITH block has its body indented, so a query built from three CTEs reads as three named blocks followed by a short final SELECT. That is usually the moment someone notices two of the blocks are filtering on different date ranges.
Dialects, and why the choice matters
Uppercase keywords are the older convention and still the most common in reviews, because they separate language from identifiers at a glance — SELECT order_id reads differently from select order_id. Lowercase is increasingly popular in teams whose editors already colour keywords. Either is defensible; a file that mixes both is not, which is what the case setting exists for.
The dialect list here is not decorative. SQL Server's TOP, Oracle's PL/SQL blocks, MySQL's backtick quoting and PostgreSQL's dollar-quoted strings are genuinely different grammars, and a formatter parsing one as another will mangle it. Only dialects the parser actually implements are offered — nineteen of them, including PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, BigQuery and Snowflake.
Whichever you choose, the value is that every query in the repository looks the same, so a pull request shows changed logic instead of changed whitespace. Agreeing the settings once, reformatting the existing files, and formatting everything afterwards costs an afternoon and removes an entire category of review comment.