SQL Formatting Best Practices: Readable Queries That Scale

SQL queries get read far more often than they get written. Six months after you write a query, someone — often you — will open it to debug a data issue or extend a feature. Formatting is what makes that possible at a glance. This guide covers the conventions that keep SQL readable without pretending there is one mandatory style.

Why formatting matters

A query's logic lives in its clauses — SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY. When each clause starts on its own line and indentation shows nesting, you can scan the structure in seconds. When everything runs together on one line, even a correct query hides its intent.

The core conventions

• One clause per line — start SELECT, FROM, WHERE, and friends on new lines
• Capitalize keywords — SELECT, FROM, JOIN in uppercase, identifiers in lowercase or snake_case
• Indent subqueries — each nested level indents by two or four spaces
• List columns one per line — when a SELECT has more than a few columns, give each its own line with a leading comma or trailing comma, consistently
• Align or indent JOIN conditions — put ON clauses on their own line

A before/after example

Before — hard to scan:

SELECT u.id,u.name,o.total FROM users u JOIN orders o ON u.id=o.user_id WHERE o.total>100 AND u.active=1 ORDER BY o.total DESC;

After — structure is visible:

SELECT u.id, u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.total > 100 AND u.active = 1 ORDER BY o.total DESC;

Nothing changed except layout — but the second version communicates its shape immediately.

Aliases and naming

Short aliases like u and o are fine in a query, as long as they are consistent. Prefer descriptive names for anything that appears in many places, and always alias aggregates (SUM(o.total) AS total_revenue) so the output column names make sense. Avoid reserved words as identifiers, and be consistent with quoting conventions across the codebase.

Formatting style is a team decision

There is no single universally correct style — teams disagree on whether commas lead or trail, and on two-space versus four-space indentation. The important thing is consistency within a project. Pick a convention, document it, and apply it automatically. Debating style in code review is a waste; enforcing it with a formatter is not.

Long queries

Long queries benefit from the same rules applied more aggressively: break complex WHERE conditions into indented lines with clear boolean operators, give subqueries their own indentation level, and consider WITH (common table expressions) to name intermediate results instead of nesting subqueries four levels deep. A readable query is easier to optimize, because you can see what it actually computes.

Format with a tool

When you inherit a one-line monster or want a consistent baseline, SQL Formatter applies standard indentation and capitalization instantly, in your browser, with no code leaving your machine. Use it to normalize before committing, then apply your team's tweaks on top. Combined with the JSON formatting guide, it keeps both of the formats you will touch most in clean shape.