SQL Formatting Best Practices for Clean Queries

Every database professional has inherited a query that looked like someone threw keywords at a wall. Proper SQL formatting transforms unreadable walls of text into structured, scannable code that anyone on your team can understand in seconds. Whether you're writing a quick ad-hoc query or building a stored procedure that will live in production for years, how you format your SQL matters enormously.

You can paste any messy query into our SQL Formatter and get clean, properly indented output instantly — but understanding why certain formatting choices work better will make you a stronger SQL developer overall.

Why SQL Formatting Matters

Poorly formatted SQL creates cascading problems across your entire workflow:

• Debugging takes three times longer — When a query returns wrong results, you need to visually trace the logic. Messy formatting hides logical errors.
• Code reviews stall — Reviewers spend time deciphering structure instead of evaluating logic.
• Merge conflicts multiply — Inconsistent formatting means every team member reformats differently, creating unnecessary git diffs.
• Onboarding suffers — New team members struggle to understand business logic buried in tangled queries.
• Production incidents escalate — Under pressure, nobody wants to untangle a 200-line query with no line breaks.

Here's the thing: SQL formatting isn't about aesthetics. It's about reducing cognitive load. A well-formatted query communicates its intent before you've even read the column names.

Keyword Casing: Pick a Convention and Stick With It

The most debated SQL formatting topic is keyword casing. There are three common approaches:

UPPERCASE keywords (most common):

SELECT
    u.first_name,
    u.last_name,
    o.order_total
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE o.order_date >= '2025-01-01'
ORDER BY o.order_total DESC;

lowercase keywords:

select
    u.first_name,
    u.last_name,
    o.order_total
from users u
inner join orders o on u.id = o.user_id
where o.order_date >= '2025-01-01'
order by o.order_total desc;

Title Case keywords:

Select
    u.first_name,
    u.last_name,
    o.order_total
From users u
Inner Join orders o On u.id = o.user_id
Where o.order_date >= '2025-01-01'
Order By o.order_total Desc;

UPPERCASE keywords remain the industry standard, and for good reason. They create an immediate visual separation between SQL keywords and your table/column names. Your eyes can scan the left margin and instantly understand the query structure: SELECT, FROM, WHERE, ORDER BY.

Worth noting: whatever convention you choose, enforce it with an automated tool. Our SQL Formatter handles keyword casing automatically, so your entire team stays consistent without thinking about it.

Indentation Strategies for Major Clauses

Good indentation is the backbone of readable SQL. Each major clause should start at the left margin, and its contents should be indented one level.

SELECT Clause

Put each column on its own line. This makes it trivial to add, remove, or comment out columns:

SELECT
    e.employee_id,
    e.first_name,
    e.last_name,
    e.department_id,
    d.department_name,
    e.hire_date,
    e.salary
FROM employees e
INNER JOIN departments d ON e.department_id = d.id;

Avoid this common anti-pattern:

-- Hard to scan, hard to modify
SELECT e.employee_id, e.first_name, e.last_name, e.department_id, d.department_name, e.hire_date, e.salary
FROM employees e INNER JOIN departments d ON e.department_id = d.id;

FROM and JOIN Clauses

Each JOIN gets its own line. The ON condition stays with its JOIN, indented further if it spans multiple conditions:

SELECT
    o.order_id,
    c.customer_name,
    p.product_name,
    oi.quantity,
    oi.unit_price
FROM orders o
INNER JOIN customers c
    ON o.customer_id = c.id
INNER JOIN order_items oi
    ON o.id = oi.order_id
LEFT JOIN products p
    ON oi.product_id = p.id
WHERE o.status = 'completed'
    AND o.order_date >= '2025-01-01';

WHERE Clause

Each condition gets its own line. Put the boolean operator (AND/OR) at the beginning of each new line — this makes it dead simple to comment out individual conditions during debugging:

WHERE o.status = 'completed'
    AND o.order_date >= '2025-01-01'
    AND o.order_date < '2026-01-01'
    AND c.region IN ('US', 'CA', 'UK')
    -- AND o.total > 100  (temporarily disabled)

The good news: once you internalize this pattern, you'll spot logical errors much faster. Each condition is visually isolated, so missing or incorrect filters jump out immediately.

Formatting Complex JOINs

Real-world queries rarely have simple single-column JOINs. Here's how to handle multi-condition JOINs cleanly:

SELECT
    s.sale_id,
    s.sale_date,
    p.product_name,
    w.warehouse_name,
    i.quantity_on_hand
FROM sales s
INNER JOIN products p
    ON s.product_id = p.id
LEFT JOIN inventory i
    ON p.id = i.product_id
    AND i.warehouse_id = s.warehouse_id
    AND i.snapshot_date = s.sale_date
LEFT JOIN warehouses w
    ON i.warehouse_id = w.id
WHERE s.sale_date >= '2025-06-01';

Notice how the additional JOIN conditions are indented to the same level as the first ON condition. This makes it clear that all three conditions belong to the same JOIN — not to a WHERE clause that was accidentally misplaced.

For self-joins, use meaningful aliases instead of cryptic single letters:

SELECT
    mgr.first_name AS manager_name,
    emp.first_name AS employee_name,
    emp.hire_date
FROM employees emp
INNER JOIN employees mgr
    ON emp.manager_id = mgr.employee_id
WHERE mgr.department_id = 10;

CTE Formatting (WITH Clauses)

Common Table Expressions deserve special formatting attention because they can make or break the readability of complex queries. Each CTE should be treated as its own formatted block:

WITH monthly_revenue AS (
    SELECT
        DATE_TRUNC('month', order_date) AS revenue_month,
        SUM(order_total) AS total_revenue,
        COUNT(DISTINCT customer_id) AS unique_customers
    FROM orders
    WHERE order_date >= '2025-01-01'
    GROUP BY DATE_TRUNC('month', order_date)
),

customer_segments AS (
    SELECT
        customer_id,
        SUM(order_total) AS lifetime_value,
        CASE
            WHEN SUM(order_total) >= 10000 THEN 'platinum'
            WHEN SUM(order_total) >= 5000 THEN 'gold'
            WHEN SUM(order_total) >= 1000 THEN 'silver'
            ELSE 'bronze'
        END AS segment
    FROM orders
    GROUP BY customer_id
)

SELECT
    mr.revenue_month,
    mr.total_revenue,
    mr.unique_customers,
    COUNT(CASE WHEN cs.segment = 'platinum' THEN 1 END) AS platinum_count,
    COUNT(CASE WHEN cs.segment = 'gold' THEN 1 END) AS gold_count
FROM monthly_revenue mr
CROSS JOIN customer_segments cs
GROUP BY mr.revenue_month, mr.total_revenue, mr.unique_customers
ORDER BY mr.revenue_month;

Key CTE formatting rules:

• Separate CTEs with a blank line after each closing parenthesis and comma
• Indent the body of each CTE as you would any regular query
• Use descriptive CTE names — monthly_revenue beats cte1 every time
• Keep the final SELECT at the same indentation level as the WITH keyword

Subquery Formatting

Subqueries should be indented one level deeper than the surrounding query. Use parentheses as visual boundaries:

SELECT
    d.department_name,
    d.budget,
    dept_stats.avg_salary,
    dept_stats.employee_count
FROM departments d
INNER JOIN (
    SELECT
        department_id,
        AVG(salary) AS avg_salary,
        COUNT(*) AS employee_count
    FROM employees
    WHERE status = 'active'
    GROUP BY department_id
    HAVING COUNT(*) >= 5
) dept_stats
    ON d.id = dept_stats.department_id
WHERE d.budget > 100000
ORDER BY dept_stats.avg_salary DESC;

When you've got nested subqueries going three or four levels deep, that's usually a sign to refactor into CTEs instead. CTEs flatten the nesting and give each logical step a readable name. Our SQL Formatter can help you identify deeply nested structures that might benefit from refactoring.

CASE Statement Formatting

CASE statements show up everywhere — in SELECT lists, WHERE clauses, ORDER BY, and even JOIN conditions. Keep them readable with consistent indentation:

SELECT
    order_id,
    order_total,
    CASE
        WHEN order_total >= 1000 THEN 'high-value'
        WHEN order_total >= 100 THEN 'medium-value'
        ELSE 'low-value'
    END AS order_tier,
    CASE status
        WHEN 'shipped' THEN 'In Transit'
        WHEN 'delivered' THEN 'Complete'
        WHEN 'returned' THEN 'Refund Pending'
        ELSE 'Processing'
    END AS display_status
FROM orders;

The WHEN and ELSE keywords align with each other, and the END keyword aligns with CASE. This creates a clean visual block that's easy to scan and modify.

Comment Best Practices in SQL

SQL comments are your future self's best friend. Use them strategically:

Block comments for query purpose:

/*
 * Monthly Revenue Report
 * Generates revenue breakdown by product category
 * Used by: Finance dashboard (Tableau)
 * Last modified: 2025-06-15
 */
SELECT
    pc.category_name,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM order_items oi
INNER JOIN products p ON oi.product_id = p.id
INNER JOIN product_categories pc ON p.category_id = pc.id
GROUP BY pc.category_name;

Inline comments for non-obvious logic:

WHERE o.order_date >= '2025-01-01'
    AND o.status != 'cancelled'
    AND o.payment_verified = TRUE    -- excludes pending payment reviews
    AND c.account_type != 'internal' -- staff test orders use internal accounts

Section comments for long queries:

-- === Revenue Calculation ===
...
-- === Customer Filtering ===
...
-- === Final Aggregation ===

Avoid over-commenting obvious things. -- select all columns above a SELECT statement adds noise, not clarity.

Formatting for Different SQL Dialects

SQL dialects have their own syntax quirks, but formatting principles stay consistent. Here are dialect-specific considerations:

MySQL

SELECT
    product_name,
    price,
    IFNULL(discount, 0) AS discount,
    price - IFNULL(discount, 0) AS final_price
FROM products
WHERE category_id IN (1, 3, 5)
LIMIT 50 OFFSET 100;

PostgreSQL

SELECT
    product_name,
    price,
    COALESCE(discount, 0) AS discount,
    price - COALESCE(discount, 0) AS final_price
FROM products
WHERE category_id = ANY(ARRAY[1, 3, 5])
LIMIT 50 OFFSET 100;

SQL Server

SELECT TOP 50
    product_name,
    price,
    ISNULL(discount, 0) AS discount,
    price - ISNULL(discount, 0) AS final_price
FROM products
WHERE category_id IN (1, 3, 5)
ORDER BY price DESC
OFFSET 100 ROWS FETCH NEXT 50 ROWS ONLY;

Regardless of dialect, the structural formatting stays the same: keywords on their own lines, consistent indentation, one column per line. The SQL Formatter on alltools.one handles all major dialects, so you get consistent results no matter which database you're working with.

Automated Formatting vs. Manual Formatting

Manual formatting works fine for short queries. But once your team grows beyond two people, you need automated enforcement. Here's why:

Benefits of automated formatting:

• Zero debates — The formatter decides, everyone follows
• Consistent git diffs — No more whitespace-only changes cluttering pull requests
• Speed — Reformatting a 500-line stored procedure by hand takes minutes. A tool does it in milliseconds.
• Onboarding — New team members don't need to memorize style guides

When manual formatting still wins:

• Alignment of specific columns in INSERT statements or complex CASE blocks
• Preserving intentional formatting in documentation queries
• Edge cases where automated tools break readability (rare, but it happens)

The pragmatic approach: use automated formatting as your baseline, then hand-tune the few queries where it matters. Run your SQL through our SQL Formatter first, then adjust specific sections if needed.

Quick Reference: SQL Formatting Checklist

Before committing any SQL to your codebase, run through this checklist:

• Keywords are consistently cased (preferably UPPERCASE)
• Each major clause (SELECT, FROM, WHERE, GROUP BY, ORDER BY) starts on a new line
• Columns in SELECT are one-per-line
• JOINs are each on their own line with ON conditions indented
• WHERE conditions are one-per-line with AND/OR at the start
• CTEs have descriptive names and consistent indentation
• CASE statements have WHEN/ELSE aligned
• Comments explain why, not what
• Table aliases are meaningful (not just single letters for complex queries)
• Subqueries deeper than two levels have been refactored into CTEs

Related Resources

If you're working on broader code quality, these guides complement SQL formatting well:

• JSON Formatting Best Practices — Similar formatting principles for JSON data structures
• Text Diff Comparison Guide — Useful for reviewing formatting changes across SQL files
• Regex Cheat Sheet — Handy for writing SQL pattern matching with LIKE and SIMILAR TO

Clean SQL formatting is one of those practices that costs almost nothing to adopt but pays dividends every single day. Your future self — and every teammate who touches your queries — will thank you.

---

🛠️ Try it now: SQL Formatter — Format and beautify SQL queries instantly. 100% free, processes everything in your browser. No data uploaded.

---