SQL Formatting Best Practices — 10 Rules for Clean, Readable SQL

1. Uppercase All SQL Keywords

This is rule number one for a reason. Uppercase keywords create a visual hierarchy that separates SQL syntax from your data identifiers (table names, column names). Your brain should be able to scan a query and instantly distinguish commands from objects.

Bad

select id, name, email from users where status = 'active' order by created_at desc;

Good

SELECT id, name, email
FROM users
WHERE status = 'active'
ORDER BY created_at DESC;

Notice how SELECT, FROM, WHERE, and ORDER BY pop out in uppercase. The column names and values stay lowercase — your eye naturally separates structure from data. This rule applies to all dialects: MySQL, PostgreSQL, T-SQL, SQLite — every one of them.

2. One Clause Per Line

Every major SQL clause — SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT — gets its own line. No exceptions. This transforms a wall of text into a scannable list of operations.

Bad

SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'completed' GROUP BY u.name HAVING SUM(o.total) > 100 ORDER BY o.total DESC;

Good

SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed'
GROUP BY u.name
HAVING SUM(o.total) > 100
ORDER BY o.total DESC;

Each clause starts at the left margin. You can read the query from top to bottom like a recipe: select these columns, from these tables, joined this way, filtered by this condition, grouped, filtered again, sorted. No scrolling sideways, no squinting.

3. Indent Subqueries and Nested Logic

Subqueries and nested SELECT statements need their own indentation level. Use 2 or 4 spaces for each nesting level. This creates a visual tree that mirrors the query's logical structure.

Bad

SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) AS order_count
FROM users
WHERE (SELECT SUM(amount) FROM payments WHERE payments.user_id = users.id) > 500;

Good

SELECT
  name,
  (SELECT COUNT(*)
   FROM orders
   WHERE orders.user_id = users.id) AS order_count
FROM users
WHERE (
  SELECT SUM(amount)
  FROM payments
  WHERE payments.user_id = users.id
) > 500;

Each subquery is indented 2 spaces from its parent. The opening and closing parentheses align with the subquery's SELECT — this is especially important for correlated subqueries where readability directly affects correctness.

4. Format Comma-Separated Lists Vertically

When selecting more than 2 columns, put each column on its own line with a trailing comma. This makes diffs clean — adding or removing a column changes exactly one line. Trailing commas are valid in modern SQL and prevent syntax errors when reordering.

Bad

SELECT id, first_name, last_name, email, phone, address, city, state, zip, created_at FROM customers;

Good

SELECT
  id,
  first_name,
  last_name,
  email,
  phone,
  address,
  city,
  state,
  zip,
  created_at
FROM customers;

Pro tip: use leading commas (comma before each column) if your team prefers it. Either style works — just pick one and stay consistent. The key is vertical alignment, not horizontal cramming.

5. Align JOIN Conditions Clearly

Each JOIN should clearly show the relationship between tables. Put the ON condition on the same line as the JOIN for simple conditions, or indent it underneath for complex multi-column joins.

Good — Simple JOIN

SELECT u.name, o.order_date, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
LEFT JOIN payments p ON o.id = p.order_id
WHERE o.status = 'shipped';

Good — Complex JOIN

SELECT u.name, o.order_date, p.amount
FROM users u
JOIN orders o
  ON u.id = o.user_id
  AND o.created_at >= '2026-01-01'
LEFT JOIN payments p
  ON o.id = p.order_id
  AND p.status = 'completed';

Multi-condition joins get their conditions stacked with consistent indentation. This makes it obvious when a join has extra filtering.

6. Use Meaningful Table Aliases

Single-letter aliases (a, b, c) are lazy and force readers to scroll back to the FROM clause. Use short but meaningful aliases — usually the first letter or a 2-3 letter abbreviation of the table name.

Bad

SELECT a.name, b.total, c.amount
FROM users a
JOIN orders b ON a.id = b.user_id
JOIN payments c ON b.id = c.order_id;

Good

SELECT usr.name, ord.total, pay.amount
FROM users usr
JOIN orders ord ON usr.id = ord.user_id
JOIN payments pay ON ord.id = pay.order_id;

The aliases usr, ord, and pay are immediately recognizable. A developer coming to this query fresh does not need to trace back what a or b means. This rule is especially important in queries with 5+ joins and CTEs where context switching is expensive.

7. Break Long CASE Expressions

CASE expressions can span dozens of lines. Format them so each WHEN/THEN pair sits on its own line, and the ELSE and END align with CASE.

Good

SELECT
  order_id,
  total,
  CASE
    WHEN total < 50 THEN 'Small'
    WHEN total BETWEEN 50 AND 200 THEN 'Medium'
    WHEN total BETWEEN 201 AND 1000 THEN 'Large'
    ELSE 'Enterprise'
  END AS order_tier
FROM orders;

The CASE and END keywords line up vertically, and each condition gets its own line. This pattern scales to CASE expressions with 20+ branches.

8. Format CTEs (Common Table Expressions) for Readability

CTEs make complex queries manageable, but only if you format them well. Each CTE gets its own indentation block, and the final SELECT sits at the left margin.

Good

WITH monthly_sales AS (
  SELECT
    user_id,
    DATE_TRUNC('month', order_date) AS month,
    SUM(total) AS revenue
  FROM orders
  WHERE status = 'completed'
  GROUP BY user_id, DATE_TRUNC('month', order_date)
),
top_customers AS (
  SELECT
    user_id,
    SUM(revenue) AS total_revenue
  FROM monthly_sales
  GROUP BY user_id
  HAVING SUM(revenue) > 10000
)
SELECT usr.name, tc.total_revenue
FROM top_customers tc
JOIN users usr ON tc.user_id = usr.id
ORDER BY tc.total_revenue DESC;

Each CTE is clearly separated by a comma after the closing parenthesis. The CTE body is indented 2 spaces. This pattern is the de facto standard in the dbt community and is recommended by SQLFluff.

9. Add Strategic Comments

Comments should explain why, not what. The SQL itself explains what the query does. Comments fill in the business logic, edge cases, and assumptions that are not obvious from the code.

Good

-- Exclude test accounts and internal admin users
-- See: https://wiki.internal/order-status-definitions
SELECT usr.name, ord.total
FROM users usr
JOIN orders ord ON usr.id = ord.user_id
WHERE usr.email NOT LIKE '%@test.internal'
  AND usr.role != 'admin'
  -- Status 4 = refunded, excluded per finance policy Q3-2026
  AND ord.status != 4;

The comments explain the business rules behind the filters — things a future developer would not know without tribal knowledge. Avoid comments like -- join users table or -- filter by status — these repeat what the code already says.

10. Be Consistent — Pick a Style and Stick to It

The single most important rule: consistency beats any specific preference. Whether you use 2 spaces or 4, leading commas or trailing commas, uppercase or lowercase keywords — pick one style and apply it across your entire codebase. Mixed styles are worse than a "wrong" style applied consistently.

If your team does not have a SQL style guide yet, start with these defaults:

• Keywords: UPPERCASE
• Identifiers: lowercase_with_underscores
• Indentation: 2 spaces
• Commas: trailing (after each item)
• Aliases: meaningful abbreviations (usr, ord, pay)
• Line width: max 100 characters

Better yet, automate it. Use SQLFormat.io to apply a consistent style to every query instantly — no manual reformatting, no style arguments.

FAQ — SQL Formatting Best Practices