Why SQL Formatting Matters
SQL is simultaneously one of the oldest and most ubiquitous programming languages in production software. Virtually every application that persists data touches SQL at some point, whether through a raw query, an ORM-generated statement, or a stored procedure.
Yet SQL has no official formatting standard. Unlike Python (PEP 8) or JavaScript (Prettier), there is no canonical style guide. The result is that SQL written by different developers on the same team frequently looks completely different — different capitalisation conventions, different indentation, different line-break placement.
Consistent formatting is not cosmetic. It reduces the cognitive load of reading queries, makes code review faster, and makes it easier to spot logic errors.
The Core Conventions
Keyword casing. The dominant convention is UPPERCASE for SQL keywords — SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY. Some teams prefer lowercase, but the key is consistency.
One clause per line. Each major clause starts on a new line:
SELECT
u.id,
u.email,
COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2024-01-01'
GROUP BY u.id, u.email
ORDER BY order_count DESC;
Indentation. Sub-expressions and column lists are indented by two or four spaces. Nested subqueries are indented relative to their parent.
Trailing vs. leading commas. Both are common. Leading commas (, column) make it easier to add/remove the last column without touching adjacent lines. Trailing commas are more natural to read. Pick one and stick to it.
Aliases. Use AS explicitly: COUNT(o.id) AS order_count. It is clearer than the implicit alias syntax supported by some dialects.
How Auto-Formatters Work
An SQL formatter tokenises the query — splitting it into keywords, identifiers, operators, literals, and punctuation — then rebuilds the output according to a set of formatting rules. This is the same basic approach used by Prettier for JavaScript.
The tricky part is dialect support. SQL is not one language — PostgreSQL, MySQL, SQLite, T-SQL (SQL Server), and BigQuery all have extensions and syntax quirks. A good formatter recognises the dialect and applies the right rules.
When Formatting Reveals Bugs
Formatting a query often surfaces structural issues that are invisible in a wall of unindented text. Common discoveries:
- A
WHEREclause that was accidentally placed before aJOIN(causing a cross join) - A missing closing parenthesis in a subquery
- An
ORcondition that was not wrapped in parentheses, changing operator precedence - Duplicate column names in a
SELECT
Integration in a Development Workflow
For production codebases, SQL formatting is most valuable when integrated with version control. A pre-commit hook or CI check that auto-formats SQL ensures that all queries in the codebase look the same regardless of who wrote them.
For ad-hoc queries — debugging, analytics, or exploration — an online formatter is the fastest option. Paste, format, read, edit.
Try It
The SQL Formatter on Syntaxly uses the sql-formatter library which supports multiple SQL dialects. Paste your query and get cleanly indented, keyword-cased SQL in one click.