Unlike most programming languages, SQL has no dominant formatter that everyone just runs (think Prettier for JS, gofmt for Go). The result is that SQL in most codebases is formatted however the person who last touched it felt like formatting it — which makes even simple queries slower to review than they should be.
SELECT
id,
email,
created_at
FROM users
WHERE status = 'active'
AND created_at > '2026-01-01'
ORDER BY created_at DESC;Putting major clauses (`SELECT`, `FROM`, `WHERE`, `ORDER BY`) at the start of their own line, left-aligned, makes a query's overall structure scannable in a fraction of a second — you can tell what's being selected, from where, and under what conditions without reading every token.
A `SELECT` with two columns is fine on one line. A `SELECT` with eight columns crammed onto one line is not — diffs become unreadable, because adding one column at the end shows up as a change to the entire line in most diff tools. One column per line makes future diffs local to the column that actually changed.
This is a convention, not a requirement, but it's the most common one and worth adopting consistently: `SELECT`, `FROM`, `WHERE`, `JOIN` in caps; table and column names in lowercase (`users`, `created_at`). It gives an instant visual split between "SQL syntax" and "your schema" without needing syntax highlighting.
The exact rules above are less important than picking one convention and applying it everywhere — a codebase where every query follows the same shape is far easier to review than one that technically follows "better" individual choices inconsistently. The SQL Formatter supports PostgreSQL, MySQL, SQLite, and SQL Server dialects specifically so pasting in a real query from any of those engines produces consistent, reviewable output instead of a one-off manual cleanup.