SQL Formatting Best Practices

SQL queries have a way of growing. What starts as a simple SELECT * FROM users WHERE active = true often ends up, a few iterations later, as a query with four joins, a subquery, a CASE expression, and a GROUP BY clause, all crammed onto one line because that's how it was typed in the first place. Consistent formatting is the difference between a query a teammate can review in thirty seconds and one that takes five minutes just to parse visually.

Why SQL Formatting Is Different From Code Formatting

Most programming languages have widely agreed-upon formatting conventions enforced by tools like Prettier or gofmt, with little room for debate. SQL formatting is less settled, partly because SQL predates most modern formatting tooling, and partly because different teams genuinely prefer different conventions for where clauses break and how deeply nested subqueries indent. That said, a few principles hold up well across most styles.

Principle 1: One Clause Per Line

The major clauses of a query, SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, and each JOIN, should each start on their own line. This turns a query's structure into something you can scan top to bottom without reading every character:

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

Compare that to the same query on one line, functionally identical, but far harder to review for correctness, especially once a query has more than two or three clauses.

Principle 2: Consistent Keyword Casing

Pick either uppercase (SELECT, FROM, WHERE) or lowercase (select, from, where) keyword casing, and apply it consistently. Uppercase keywords are the more traditional convention and make it easy to visually distinguish SQL keywords from table and column names at a glance, which is especially useful in queries with many identifiers. Lowercase has become more common in codebases that treat SQL similarly to other application code, where uppercase keywords can feel like unnecessary shouting.

Whichever you choose, consistency matters more than the specific choice, a query that mixes SELECT and from in the same statement is harder to read than one that picks either convention and sticks with it.

Principle 3: Indent Nested Structures

Subqueries, CASE expressions, and nested boolean logic should be indented relative to their parent clause, the same way nested blocks are indented in any other language:

SELECT
  id,
  CASE
    WHEN total > 1000 THEN 'high'
    WHEN total > 100 THEN 'medium'
    ELSE 'low'
  END AS tier
FROM
  orders
WHERE
  user_id IN (
    SELECT id
    FROM users
    WHERE active = true
  )

Without indentation, it's genuinely difficult to tell where a subquery starts and ends, especially once a query has more than one level of nesting.

Principle 4: Align Related Conditions

When a WHERE clause has multiple conditions joined by AND or OR, put each condition on its own line with the boolean operator leading the line, rather than trailing:

WHERE
  u.active = true
  AND u.created_at > '2026-01-01'
  AND o.status != 'cancelled'

This makes it easy to scan down the left edge and see exactly how many conditions there are and how they're combined, and makes adding or removing a condition a clean single-line diff in version control.

Principle 5: Use Meaningful Table Aliases

This is more of a naming convention than a formatting rule, but it affects readability just as much. Single-letter aliases like u for users and o for orders are fine and widely used, but only when they're derived predictably from the table name. Avoid aliases like a, b, c that give no hint about what table they refer to, a reader shouldn't have to scroll back up to the FROM clause every time they see a column reference.

SQL Dialects Are Not Identical

Unlike JSON, which has one specification everyone agrees on, SQL is really a family of related-but-different dialects. Standard SQL defines the core language, but PostgreSQL, MySQL, SQLite, SQL Server (T-SQL), and others each extend it with their own functions, syntax for pagination, date handling, and more. A formatter that handles standard SELECT/FROM/WHERE structure well will generally do a good job across dialects, since the core clause structure is shared, but dialect-specific syntax (like SQL Server's TOP versus standard LIMIT, or PostgreSQL's RETURNING clause) may format less predictably. When in doubt, choose the dialect setting that matches your target database, and treat the output as a strong starting point rather than an infallible result, no formatter can claim perfect support for every vendor-specific extension.

Formatting as a Debugging Tool

Beyond readability, reformatting a query you didn't write yourself is often the fastest way to actually understand it. A query that looks intimidating as a dense paragraph frequently turns out to be simple once each clause is on its own line and indentation reveals the nesting structure. This is especially useful when debugging a slow query, seeing the join structure clearly makes it much easier to reason about which joins might be scanning more rows than expected.

Try It

Our SQL Formatter applies these conventions automatically: one clause per line, consistent uppercase keywords, and proper indentation for nested structures, with support for several common SQL dialects. Paste in a dense one-line query and get back something you can actually review, entirely in your browser, with nothing sent to a server and no query ever executed.