SQL formatting conventions: keyword case, commas, and team style guides

Badly formatted SQL is not wrong SQL, it is expensive SQL: the query runs fine, but every engineer who reads it later spends extra seconds parsing where one clause ends and the next begins. Formatting conventions exist to spend that cost once, in the style guide, rather than on every review.

Keyword case

The oldest convention is uppercase keywords, lowercase identifiers:

SELECT id, email, created_at
FROM users
WHERE active = true;

The reasoning is scannability: SELECT, FROM, WHERE, and JOIN jump out as structure, while table and column names stay quiet. SQL itself is case insensitive for keywords, so this is purely a reading aid. Some modern teams prefer all lowercase, arguing that syntax highlighting already does the job of distinguishing keywords and that lowercase is faster to type and calmer to read. Both are defensible. What is not defensible is mixing them within a codebase.

Leading versus trailing commas

This is the formatting debate with the strongest practical argument on one side. Trailing commas are the familiar style:

SELECT
    id,
    email,
    created_at
FROM users

Leading commas put the comma at the start of each line:

SELECT
    id
  , email
  , created_at
FROM users

Leading commas look odd at first, but they have a real benefit: the last column and the first column are the only lines without a leading comma, and adding or removing a column in the middle never touches another line. The classic trailing comma bug, a dangling comma after the final column when you delete the last line, simply cannot happen with leading commas because the comma belongs to the line being added, not the line before it. That makes diffs cleaner and the common mistake impossible.

Indentation and join alignment

Put each major clause on its own line and indent its contents. Joins are where readability is won or lost, because a query with several joins and conditions becomes unreadable when flattened:

SELECT o.id, c.name
FROM orders AS o
JOIN customers AS c
    ON c.id = o.customer_id
LEFT JOIN refunds AS r
    ON r.order_id = o.id
WHERE o.created_at >= '2026-01-01';

Aligning the ON under its JOIN, and keeping one join per line with its condition indented, lets a reader trace the relationships top to bottom. Always alias tables consistently and qualify every column with its alias in a multi table query, so no reader has to guess which table name came from.

Why a team style guide beats taste

Every convention above has a reasonable argument on each side, which means there is no universally correct answer, only a locally consistent one. The value is not in which style you pick but in picking one and applying it everywhere, because consistency is what lets a reader stop parsing layout and start reading logic. A shared style also makes diffs meaningful: when formatting is uniform and automated, a diff shows only real changes, not one engineer's reflow of another's spacing.

The lazy and correct move is to encode the choice in a formatter and run it automatically, so the debate happens once and never again in review. Nobody should be hand aligning ON clauses in 2026.

Paste a messy query and get it formatted to a consistent style instantly with the SQL Formatter, then agree the options as your team default.