Developer

How to Format SQL Before Sharing It With a Teammate

Published March 24, 2026 · Updated March 26, 2026 · 3 min read

SQL shared for code review in its raw, unformatted state is harder to review than it needs to be. The reviewer has to mentally parse the structure before they can check the logic. A formatted query separates concerns clearly — what's being selected, from where, under what conditions, in what order.

What good SQL formatting looks like

The main conventions that make SQL readable:

-- Uppercase keywords, lowercase identifiers
SELECT
    u.id,
    u.name,
    COUNT(o.id) AS order_count,
    SUM(o.total) AS total_spent
FROM users u
LEFT JOIN orders o
    ON u.id = o.user_id
WHERE
    u.created_at >= '2026-01-01'
    AND u.active = TRUE
GROUP BY
    u.id,
    u.name
HAVING
    COUNT(o.id) > 0
ORDER BY
    total_spent DESC
LIMIT 20;

Key formatting choices here: keywords uppercase, identifiers lowercase; each column on its own line in the SELECT; JOIN condition indented under the JOIN; WHERE conditions listed separately with AND at the start of each new condition; GROUP BY and HAVING on separate lines.

Why formatting matters for code review

When a teammate reviews unformatted SQL, they spend cognitive effort on structure before they can think about logic. Formatted SQL lets a reviewer immediately see: what tables are involved (FROM and JOIN clauses), how they're connected (ON conditions), what rows are included (WHERE), how results are grouped (GROUP BY), and what's returned (SELECT).

Subtle bugs — a missing JOIN condition that accidentally produces a Cartesian product, a WHERE clause that uses OR when AND was intended — are much easier to spot in formatted SQL because each logical component is visually distinct.

SQL dialect formatting differences

MySQL, PostgreSQL, and BigQuery have different conventions for quoting identifiers, handling case sensitivity, and writing window functions. A SQL formatter that knows the target dialect produces more idiomatic output:

MySQL uses backtick quoting: `table_name`
PostgreSQL uses double quote quoting: "table_name"
BigQuery is case-insensitive for keywords and typically uses backtick quoting for project.dataset.table identifiers

Consistent style across a team: agree on a formatter and run all SQL through it before committing. This eliminates formatting debates in code review and makes diffs show only logical changes, not formatting changes.

When not to format

Inline SQL in strings within code is typically short enough that formatting isn't necessary. Very simple queries like SELECT * FROM users WHERE id = $1 are readable without formatting. Format SQL that's more than one or two clauses, any query with JOINs, and anything being shared for review or documentation.