SQL Formatting Style Guide: Indentation, Keyword Case, and Team Consistency

Why SQL formatting deserves a standard

A typical "incident SQL" looks like this: a query copied from logs, one line, three JOINs and six conditions crammed together, and changing one condition means finding your place among three hundred characters. Formatted, the same query shows its JOINs, condition groups, and column list at a glance — the value of formatting isn't aesthetics, it's making query structure explicit so reviewers can follow the logic.

But formatting has no single right answer: uppercase or lowercase, 2 or 4 spaces, leading or trailing commas — every team has its own taste. Without a standard, five styles coexist in the codebase and diff noise buries real changes. This guide offers a ready-to-adopt default and shows how to enforce it with tools — the highest form of a standard is one nobody has to remember.

Tool entry point first: the SQL Formatter supports 20 dialects (MySQL, PostgreSQL, SQLite, ClickHouse, Snowflake, and more) with keyword case, indent width, and blank-line controls; paste and get results, with one-click minify back to a single line. Every recommendation below can be verified with it on the spot.

Keyword case: pick a camp, then automate it

The real differences between the camps:

Our take: follow your team's majority; absent one, go uppercase — it contrasts maximally with lowercase column names. The key isn't which camp but that a tool enforces it: set the online tool's keyword case to uppercase and anything you paste comes out uniform; on the editor side, a SQL Formatter plugin (most share the same sql-formatter engine) formats on save.

One boundary to note: the case option applies to keywords, never your data — in WHERE name = 'Apple', the 'Apple' stays untouched.

Indentation and line folding: 2 or 4, and how to lay out columns

• Indent width: 2 spaces is friendlier to SQL — JOIN and subquery nesting runs deep, and 4 pushes columns off-screen fast. Follow your repo's convention when it has one.
• One column per line after SELECT, with trailing commas — adding or dropping a column is a one-line diff.
• JOIN conditions go in ON, filters in WHERE: ON o.user_id = u.id owns the join; WHERE u.status = 'active' owns filtering. Mixing them is the most-caught code smell in review, and formatting puts each back in place.
• Subqueries indent one level, aliases aligned to the outer query.

The formatter handles most of this automatically (the online tool defaults to exactly this layout); the only knobs you need are indent width and blank lines between statements.

Minify: the reverse need is real

"Folding SQL back to one line" sounds regressive, but two scenarios want it: embedding queries in logs and monitoring (single lines are searchable) and reviewing dynamically assembled SQL (flattened shows the whole). There's a subtle correctness trap: when the newline after a -- comment is collapsed, the comment swallows everything after it — a proper tool converts line comments to /* ... */ block comments first, keeping semantics intact. Minify also merges consecutive spaces inside strings, so use format, not minify, when exact spacing matters.

Making the standard stick

A complete rollout:

1. Define it: use this guide's defaults (uppercase keywords, 2 spaces, one column per line) or tweak by team vote; write it into a one-page CONTRIBUTING.
2. Enforce with tools: ad-hoc cases go through the online SQL formatter with your dialect picked; daily coding gets an editor plugin.
3. Migrate the legacy: batch-paste old scripts through the tool and review the diff — formatting never changes the execution plan, so performance risk is zero.
4. Adjacent workflow: tidy query results with the site's JSON Formatter; take data back to spreadsheets with JSON to CSV; feed CSV data into a query via CSV to JSON.

Frequently Asked Questions

Which SQL formatting tool should I use?

By scenario: for pasting a quick query, an online tool is fastest — this site's SQL formatter supports 20 dialects with keyword-case and indent controls plus one-click minify. For daily coding, use an editor plugin (VS Code's SQL Formatter family shares the same underlying engine) and bake the style into your save action.

Should SQL keywords be uppercase or lowercase?

Both camps have arguments: uppercase makes keywords stand out from identifiers (classic DBA style); lowercase reads better in modern monospace fonts and is cheaper to type. What matters is team-wide consistency — a formatter's keyword-case option (preserve/upper/lower) enforces it in one click, far more reliably than verbal agreement.

Should SQL use 2-space or 4-space indentation?

Follow your repo's dominant convention: frontend repos tend to 2, backend Java/Go to 4. For standalone SQL files, 2 is friendlier — deep JOIN nesting pushes columns off-screen at 4. The tool's indent setting helps migrate legacy scripts with minimal diff.

Does formatting change SQL performance?

No. Formatting only touches whitespace, line breaks, and keyword case; the database produces an identical execution plan, and string contents stay untouched. The only caveat: minifying converts line comments to block comments — semantically equivalent, different shape.