SQL Formatting Best Practices for 2026 — Standards That Actually Work

There is no single SQL style guide everyone agrees on. The Mozilla style guide says one thing, the GitLab data team style guide says another, and the dbt community has yet a third opinion. After looking at all of them, the practices that actually matter come down to about a dozen rules. Most teams agree on these even if they disagree on details like leading commas or 2 vs 4 space indent.

This guide covers the SQL formatting rules that survive across the popular style guides and that make queries genuinely more readable. Apply them by hand, or use a formatter that enforces them automatically.

Rule 1: Uppercase Keywords

SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY, HAVING, LIMIT — uppercase. Column and table names — whatever your database uses (typically lowercase or snake_case). Functions like COUNT, SUM, AVG — uppercase.

Why: visual contrast. When keywords are uppercase, your eye can find the structure of a query at a glance. When everything is lowercase, you have to read word-by-word to find clauses.

Counter-argument: Some style guides (notably the Mozilla one) prefer lowercase keywords for "consistency." This is a minority position. Most data teams use uppercase.

Verdict: Uppercase keywords, lowercase identifiers. This is the dominant convention in 2026.

Rule 2: Pick 2 or 4 Space Indent and Stick to It

The dbt community uses 2 spaces. The Microsoft T-SQL examples use 4 spaces. The Postgres docs use 4 spaces in places and 2 in others. Both are fine — pick one and apply it consistently across your project.

Why: consistency matters more than the specific number. Mixed indentation in the same file is the actual enemy.

Tabs vs spaces: spaces win for SQL because not all SQL editors render tabs the same way. Spaces look identical everywhere.

Verdict: 2 spaces if you are aligned with the dbt ecosystem. 4 spaces if you are in the Microsoft world. Spaces, not tabs. Never mix.

Rule 3: One Column Per Line for SELECT Lists With 4+ Columns

For SELECT id, name FROM users — one line is fine. For SELECT id, name, email, created_at, updated_at, status, role, deleted_at FROM users — one column per line.

The threshold is around 3-4 columns or when the line exceeds about 80 characters. Below that, inline. Above that, one per line.

Why: code reviews. A diff that adds or removes a column is much easier to read when columns are on separate lines. Inline lists make every change look like the entire SELECT was modified.

Bonus rule: when columns are on separate lines, put the comma at the end of each line (trailing comma). Leading commas are a minority style — they look weird to most readers.

Rule 4: Each JOIN Gets Its Own Line

When you have multiple JOINs, each one starts a new line. The JOIN keyword and the table being joined go on one line; the ON clause goes on the same line as the JOIN.

FROM users
LEFT JOIN orders ON users.id = orders.user_id
LEFT JOIN subscriptions ON users.id = subscriptions.user_id

Why: visual clarity of join order. You can count joins, spot LEFT vs INNER, and verify the ON conditions at a glance.

Variant: Some style guides put ON on the next line, indented under JOIN. Both work. Pick one.

Rule 5: WHERE and AND/OR on Separate Lines

WHERE status = 'active'
AND created_at >= '2024-01-01'
AND deleted_at IS NULL

Each AND or OR starts a new line, with the operator at the start of the line (not the end of the previous line).

Why: easy to add and remove conditions without rewriting other lines. Easy to spot the operator (AND vs OR) at the start of each line.

Bonus: Wrap complex OR groups in parentheses on their own lines.

Sell Custom Apparel — We Handle Printing & Free Shipping

Rule 6: Common Table Expressions Get Blank Lines Between Them

WITH base_data AS (
  SELECT ... FROM ...
),

filtered_data AS (
  SELECT ... FROM base_data WHERE ...
),

final_data AS (
  SELECT ... FROM filtered_data ...
)

SELECT * FROM final_data;

Each CTE is a logical unit. Blank lines between them make the boundaries visible at a glance.

Why: large analytical queries can have 10+ CTEs. Without blank lines, they merge into one wall of code.

Rule 7: Comments Explain Why, Not What

Bad: -- Get all users followed by SELECT * FROM users
The comment adds nothing. The query is self-explanatory.

Good: -- Excluding test accounts created by QA team (per ticket DATA-247) followed by WHERE email NOT LIKE '%@qa-test.example'
The comment explains business context that the SQL alone cannot convey.

Comments should answer "why is this query written this way?" not "what does this line do?" The latter is obvious from reading the SQL.

Rule 8: Aliases Are Short and Meaningful

Single-letter aliases (u for users, o for orders) are fine when the meaning is obvious from context. Avoid unrelated single letters (t for temperature_log if you also have a t for transactions in the same query).

For complex queries with many tables, use 2-3 letter aliases that hint at the table: usr for users, ord for orders, sub for subscriptions.

Avoid: AS a, AS b, AS c. These are useless. Use them only for derived columns where the original name does not matter (SELECT 1 AS a, 2 AS b for a hardcoded test case).

Rule 9: Derived Columns Always Get Aliases

SELECT COUNT(*) — bad. The result column will be named "count" or "_col0" depending on the database. Hard to reference later.

SELECT COUNT(*) AS total_users — good. The result column has a clear name, can be referenced in HAVING or ORDER BY, and is meaningful in the output.

This rule applies to: aggregate functions (COUNT, SUM, AVG), arithmetic expressions (price * quantity), string concatenations (first_name || ' ' || last_name), CASE expressions, and any subquery used as a column.

Rule 10: Use an Auto-Formatter

Hand-formatting SQL is a waste of time. Modern teams use auto-formatters that enforce style on commit (sqlfluff in CI, browser tools for ad-hoc work).

Why: consistency without willpower. New team members do not need to memorize 10 rules — the formatter applies them automatically. Code reviews stop arguing about style and focus on logic.

The browser formatter you are reading about handles the rules above automatically. Paste your query, click Format, and rules 1-9 are applied in 100ms.

When These Rules Should Be Broken

Every rule has exceptions. Bend them when:

• The query is 3 lines. Inline columns and conditions are fine for tiny queries.
• You are matching existing style. If a codebase uses 4-space indent and lowercase keywords, match it. Consistency within a file matters more than universal style.
• The query is auto-generated. ORM-generated SQL is not meant to be read by humans. Do not waste time formatting it.
• You are testing in a REPL. Hand-typing one-off queries does not need formal style.

For everything else — production queries, dbt models, runbooks, code reviews, shared documentation — apply the rules.

Frequently Asked Questions

Should I use leading commas or trailing commas?

Trailing commas are the dominant convention in 2026. Leading commas (placing the comma at the start of each new line) are a minority style preferred by some DBAs because it makes adding/removing the last column easier. Both work — pick one and stick with it.

Is uppercase keywords still the standard or has it changed?

Uppercase keywords are still the dominant convention in 2026. The minority position (lowercase keywords for consistency with other languages) has not gained traction. Most style guides, formatters, and team conventions still use uppercase.

Should I use 2 or 4 space indent?

Either works. 2 spaces is the dbt and modern data team convention. 4 spaces is the Microsoft and older Oracle convention. Pick what your team uses and apply it consistently. Do not mix them in the same project.

Is there an official SQL style guide?

No single official one. Popular style guides include the Mozilla SQL Style Guide, the GitLab Data Team SQL Style Guide, and the dbt SQL Style Guide. They agree on most things and differ on a few details like leading commas.

Do these rules matter if I use an ORM?

They matter for the SQL you write by hand for migrations, raw queries, and complex reports. They matter less for ORM-generated SQL (which you should not need to read). If you do need to debug ORM SQL, paste it into a formatter to make it readable.