Home/Blog/SQL Formatting Best Practices
SQL · Guide

SQL Formatting Best Practices

5 min readUpdated January 2025Developer Tools
Messy SQL is hard to debug, review, and maintain. This guide covers SQL formatting conventions used by professional database developers — and how to automate the cleanup with a free online SQL formatter.

Free Online SQL Formatter

Beautify raw SQL queries instantly. Supports MySQL, PostgreSQL, and more.

Open SQL Formatter →

Why SQL formatting matters

SQL queries can grow to hundreds of lines involving multiple joins, subqueries, CTEs, and window functions. Without consistent formatting, a complex query becomes nearly impossible to review in a pull request, debug in production, or hand off to another developer.

Good SQL formatting makes the logical structure of a query immediately visible — which tables are involved, what conditions apply, how data is grouped and ordered.

Keyword casing — UPPERCASE vs lowercase

The most visible formatting choice is whether SQL keywords are uppercase or lowercase. Both are valid SQL — it's a style choice. The two dominant conventions are:

StyleExampleCommon in
UPPERCASE keywordsSELECT id FROM users WHERE active = trueTraditional SQL, enterprise teams, most style guides
lowercase keywordsselect id from users where active = trueModern teams, ORM-generated SQL

The tinybench.dev SQL formatter lets you choose your preferred keyword casing — UPPERCASE, lowercase, or preserve original.

Indentation and line breaks

Each major clause should start on a new line. Use consistent indentation (2 or 4 spaces) for sub-clauses.

Before formatting
SELECT u.id, u.name, COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.active = true GROUP BY u.id, u.name HAVING COUNT(o.id) > 0 ORDER BY orders DESC LIMIT 10
After formatting
SELECT
    u.id,
    u.name,
    COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o
    ON u.id = o.user_id
WHERE u.active = true
GROUP BY
    u.id,
    u.name
HAVING COUNT(o.id) > 0
ORDER BY orders DESC
LIMIT 10

Commas — leading vs trailing

Two schools of thought exist on where to place commas in SELECT lists:

Trailing commas (most common)
SELECT
    id,
    name,
    email,
    created_at
FROM users
Leading commas (easier to comment out lines)
SELECT
    id
  , name
  , email
  , created_at
FROM users

Leading commas make it easy to comment out a line without worrying about trailing commas. Pick one style and be consistent within a project.

Aliasing tables and columns

CTE formatting

Common Table Expressions (CTEs) should be formatted with each CTE clearly separated and named descriptively:

Well-formatted CTE
WITH
active_users AS (
    SELECT id, name
    FROM users
    WHERE active = true
),
order_counts AS (
    SELECT user_id, COUNT(*) AS total
    FROM orders
    GROUP BY user_id
)
SELECT
    u.name,
    COALESCE(o.total, 0) AS orders
FROM active_users u
LEFT JOIN order_counts o
    ON u.id = o.user_id
ORDER BY orders DESC
Pro tip: Paste any query into the SQL formatter and hit Format. It handles SELECT, INSERT, UPDATE, DELETE, CTEs, subqueries, and window functions automatically.

Frequently asked questions

Does SQL formatting affect query performance?
No. SQL formatting is purely cosmetic — whitespace, line breaks, and casing have zero effect on how the database engine parses or executes the query.
Should I format SQL in stored procedures?
Absolutely. Stored procedures and views are code that other developers will need to read, review, and maintain. Consistent formatting is especially important in stored procedures because they tend to contain complex logic.
What indentation size should I use for SQL?
4 spaces is the most common convention for SQL. Some teams use 2 spaces for consistency with their other code. The key is picking one and sticking to it across the codebase.

Try it now — free & private

Runs entirely in your browser. No sign-up, no uploads, no tracking.

Open SQL Formatter →

Related tools on tinybench.dev