SQL Formatting Best Practices — A Practical Style Guide with Examples

SQL is one of the few languages where the same query can be written as an unreadable one-liner or as a clean, scannable block — and both run identically. The database does not care about formatting, but every human who reviews, debugs, or extends your query does. This guide collects the formatting conventions that most experienced teams converge on, with before/after examples, and presents the genuinely contested choices (like comma placement) fairly so you can decide for your own team.

Keyword Casing and One Clause Per Line

The two highest-impact rules are also the simplest. First, pick a case for keywords — uppercase (SELECT, FROM, WHERE) is the most common convention because it makes the query skeleton stand out from table and column names, which stay lowercase snake_case. Second, start every major clause on its own line. A clause buried mid-line is a clause a reviewer will miss.

-- Before: valid SQL, hostile to humans
select id, name, email from users where status='active' and country='India' order by created_at desc limit 20;

-- After: skeleton visible at a glance
SELECT id, name, email
FROM users
WHERE status = 'active'
  AND country = 'India'
ORDER BY created_at DESC
LIMIT 20;

Notice the second AND condition: it is indented two spaces under WHERE so the eye reads the filter as one logical block. Spaces around the = operator are part of the same habit — status = 'active' scans faster than the squeezed version.

Formatting JOINs and Multi-Condition Filters

JOINs are where formatting pays for itself. Put each JOIN on its own line, always write the join type explicitly (INNER JOIN, LEFT JOIN — never a bare comma join), and indent the ON condition so it visually belongs to its JOIN:

SELECT
  o.id,
  o.total_amount,
  c.name  AS customer_name,
  p.title AS product_title
FROM orders o
INNER JOIN customers c
  ON c.id = o.customer_id
LEFT JOIN products p
  ON p.id = o.product_id
  AND p.is_active = 1
WHERE o.created_at >= '2026-01-01'
  AND o.status IN ('paid', 'shipped');

• One JOIN per line — the FROM block becomes a readable list of data sources
• ON indented under its JOIN — extra join conditions (like p.is_active above) line up beneath
• AND conditions aligned — every filter starts at the same column, so nothing hides at the end of a long line

Alias Conventions That Actually Help

Aliases exist to reduce noise, not to create puzzles. Three rules cover almost every case:

• Use short, predictable table aliases — o for orders, c for customers, oi for order_items. Avoid meaningless letters like t1, t2, t3, which force readers to keep a mental lookup table.
• Always write AS for column aliases — SUM(amount) AS total_amount is unambiguous; omitting AS makes a missing comma between two columns silently turn one column into an alias for the other. This is a real bug class, not a style nitpick.
• Qualify every column in multi-table queries — c.name, not bare name. Unqualified columns break when a second table later gains a column with the same name.

Leading vs Trailing Commas — The Honest Trade-Off

This is the one debate where reasonable teams genuinely disagree, so here are both sides without spin:

-- Trailing commas (most common)      -- Leading commas
SELECT                                 SELECT
  id,                                    id
  customer_id,                           , customer_id
  total_amount,                          , total_amount
  created_at                             , created_at
FROM orders;                           FROM orders;

• Trailing commas read like natural language and match how nearly every other programming language formats lists. Most formatters and auto-generated SQL use them, so they dominate in the wild.
• Leading commas shine during editing: you can comment out, delete, or reorder any column except the first without touching another line, and a forgotten comma is instantly visible at the start of a line. Analysts who iterate on SELECT lists all day often prefer them for exactly this reason — diffs stay one-line clean.
• The tie-breaker — if your team reviews a lot of SQL diffs, leading commas reduce noise; if your SQL is mostly written once and read many times, trailing commas are the friendlier default. Either way, mixing both in one codebase is the only wrong answer.

Formatting CTEs

Common Table Expressions turn a nested query into a top-to-bottom story — but only if they are laid out consistently. Give each CTE its own block: name and opening parenthesis on one line, the body indented, and the closing parenthesis back at the left margin so the boundaries are obvious.

WITH monthly_sales AS (
  SELECT
    DATE_TRUNC('month', created_at) AS month,
    SUM(total_amount)               AS revenue
  FROM orders
  WHERE status = 'paid'
  GROUP BY 1
),

top_months AS (
  SELECT month, revenue
  FROM monthly_sales
  ORDER BY revenue DESC
  LIMIT 3
)

SELECT *
FROM top_months
ORDER BY month;

A blank line between CTEs and before the final SELECT gives each step breathing room. Name CTEs after what they contain (monthly_sales), never after how they were made (temp1, cte2). For a deeper look at when to reach for CTEs, see our CTE guide.

A Compact Rule Summary

• UPPERCASE keywords, lowercase snake_case identifiers
• One clause per line; SELECT columns each on their own line once there are more than two or three
• Indent continuation lines (AND, ON, THEN) two or four spaces — pick one and stick to it
• One JOIN per line, explicit join type, ON indented beneath
• Short meaningful aliases; always AS for column aliases; qualify columns in multi-table queries
• Pick a comma style, document it, enforce it with a formatter rather than in code review
• CTEs as separated blocks with descriptive names

The final point matters most: none of these rules should cost you manual effort. Run your query through a formatter and the style applies itself — which is also the only way a style survives deadlines.

Frequently Asked Questions