Guides · Formatting

SQL Formatting Best Practices for Cleaner Queries

Conventions and techniques that make SQL queries easier to read, review, and maintain.

Last updated: May 4, 2026

Why SQL formatting matters

Unformatted SQL is written in minutes and debugged for hours. A 10-line query written as a single unbroken string is nearly impossible to review in a pull request, difficult to explain to a colleague, and painful to modify six months later. Consistent formatting removes that friction.

Core formatting conventions

Uppercase reserved words

Write keywords like SELECT, FROM, WHERE, JOIN,GROUP BY, and ORDER BY in uppercase. This visually separates SQL structure from table and column names, making clause boundaries instantly recognizable.

One clause per line

Each major clause (SELECT, FROM, WHERE, JOIN,ORDER BY, LIMIT) should start on its own line. This creates a consistent visual structure and makes it easy to add, remove, or reorder clauses.

Indent continuation lines

Conditions within WHERE, join conditions, and selected column lists should be indented consistently. A two-space or four-space indent works well. The goal is that each line at the same logical level aligns visually.

Align multi-column SELECT lists

When selecting many columns, put each on its own line with a leading comma (trailing comma style also works; pick one and stay consistent). This makes the column list easy to diff and edit: adding or removing a column touches exactly one line.

Use explicit JOIN syntax

Prefer INNER JOIN / LEFT JOIN over implicit joins via a comma-separatedFROM clause. Explicit JOINs make the relationship between tables clear and prevent accidental Cartesian products.

Table aliases: meaningful over cryptic

Single-letter aliases (u, o) save typing but hurt readability in complex queries. Use short but descriptive aliases like usr, ord, or prdso the query is self-documenting.

Formatting for code review

SQL that goes into source control (migrations, stored procedures, views, seed files) deserves the same care as application code. Format it before committing. A formatter like the one on this site produces consistent output regardless of who wrote the original query, eliminating style disagreements in reviews.

If your team uses a linter or CI check, agree on a dialect (PostgreSQL, MySQL, generic SQL) and configure it consistently. Mixed dialect formatting in the same repository causes unnecessary diff noise.