SQL Formatting Best Practices: Write Clean, Readable Database Queries

Why SQL Formatting Matters

SQL is the language of data. Whether you are a backend engineer, data analyst, or full-stack developer, you write SQL queries every day. Unfortunately, bad formatting turns simple queries into unreadable messes. A well-formatted SQL query communicates intent, makes debugging faster, and helps your colleagues understand your logic at a glance.

Consistent formatting reduces syntax errors, simplifies code reviews, and makes it much easier to spot logical mistakes. When every team member follows the same style guide, your codebase stays clean and professional. If you need to quickly clean up a messy query, try our free SQL formatter online.

Capitalization: SELECT vs select

The most fundamental formatting decision is keyword casing. Most style guides recommend UPPERCASE for SQL keywords and lowercase for column and table names. This visual distinction makes it easy to separate language constructs from your data objects.

Bad formatting:

select u.name, o.total from users u join orders o on u.id = o.user_id where o.status = 'active' order by o.total desc

Good formatting:

SELECT
    u.name,
    o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.status = 'active'
ORDER BY o.total DESC

The uppercase keywords stand out immediately, and each clause starts on its own line. This small change dramatically improves readability.

Indentation Strategies

Consistent indentation is the backbone of readable SQL. Here are the most common approaches:

Four-space indentation — the most popular choice, widely used in SQL style guides.
Two-space indentation — common in projects with deeply nested subqueries to avoid line wrapping.
Align to keywords — aligning column names and conditions with a consistent column position.

Bad formatting:

SELECT customer_id, first_name, last_name, email, created_at,
phone, address_line1, address_line2, city, state, zip FROM customers WHERE created_at > '2024-01-01' AND status = 'active' ORDER BY last_name ASC, first_name ASC;

Good formatting:

SELECT
    customer_id,
    first_name,
    last_name,
    email,
    created_at,
    phone,
    address_line1,
    address_line2,
    city,
    state,
    zip
FROM customers
WHERE created_at > '2024-01-01'
    AND status = 'active'
ORDER BY last_name ASC, first_name ASC;

Each column gets its own line with consistent indentation. The WHERE conditions are also indented, making the logic crystal clear.

JOIN Formatting

JOINs are where formatting really pays off. A poorly formatted multi-table query is a nightmare to debug.

Bad formatting:

SELECT * FROM orders o left join customers c on o.customer_id = c.id left join order_items oi on o.id = oi.order_id left join products p on oi.product_id = p.id WHERE o.created_at >= '2024-06-01';

Good formatting:

SELECT
    o.id AS order_id,
    o.created_at,
    c.name AS customer_name,
    p.name AS product_name,
    oi.quantity,
    oi.price
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id
LEFT JOIN order_items oi ON o.id = oi.order_id
LEFT JOIN products p ON oi.product_id = p.id
WHERE o.created_at >= '2024-06-01'
ORDER BY o.created_at DESC;

Notice how each JOIN clause starts on a new line, the alias is placed immediately after the table name, and only the columns you actually need are selected (never use SELECT * in production).

Subquery Formatting

Subqueries add complexity and need extra care with indentation. Always alias your subqueries and indent them clearly.

Bad formatting:

SELECT name, total FROM customers WHERE id IN (SELECT customer_id FROM orders WHERE total > 1000 AND status = 'completed');

Good formatting:

SELECT
    c.name,
    c.total
FROM customers c
WHERE c.id IN (
    SELECT o.customer_id
    FROM orders o
    WHERE o.total > 1000
        AND o.status = 'completed'
);

The subquery is indented one level deeper than the outer query, and its own clauses are formatted consistently within. This makes it obvious where the subquery begins and ends.

Common SQL Style Guides

Several well-known style guides can help your team standardize:

Mozilla SQL Style Guide — uppercase keywords, new lines for major clauses, trailing commas.
GitLab SQL Style Guide — similar to Mozilla, with specific rules for CTEs and subqueries.
SQLFluff defaults — the popular linter's default ruleset, a great starting point.

Pick one guide and stick with it. Consistency matters more than which specific rule you choose.

CTE (Common Table Expression) Formatting

CTEs are one of SQL's most readable features — but only when formatted correctly.

WITH
high_value_orders AS (
    SELECT
        customer_id,
        COUNT(*) AS order_count,
        SUM(total) AS total_spent
    FROM orders
    WHERE total > 500
    GROUP BY customer_id
),
active_customers AS (
    SELECT id, name, email
    FROM customers
    WHERE status = 'active'
)
SELECT
    ac.name,
    ac.email,
    hvo.order_count,
    hvo.total_spent
FROM active_customers ac
JOIN high_value_orders hvo ON ac.id = hvo.customer_id
ORDER BY hvo.total_spent DESC;

Each CTE is named descriptively, the AS keyword is on the same line, and the body is indented. The final SELECT is separated visually from the WITH clause.

Performance vs. Readability

A common misconception is that well-formatted queries are slower. This is false. SQL formatting has zero impact on query execution. The database engine parses your query into an execution plan regardless of whitespace, capitalization, or indentation.

Always prioritize readability. Write queries for humans first and the database second. If performance is needed, focus on indexing strategies, query plans, and EXPLAIN ANALYZE — not formatting.

Tools to Help

Manually formatting SQL is tedious. Use automated tools to enforce consistency:

Our SQL formatter — paste any query and get clean, formatted output instantly.
SQLFluff — a powerful SQL linter that checks formatting in CI/CD.
Prettier SQL plugin — integrates with your editor for auto-formatting on save.

Summary

Good SQL formatting is a simple habit that pays enormous dividends. Capitalize keywords, indent consistently, format JOINs and subqueries clearly, and use CTEs for complex logic. Your future self — and everyone on your team — will thank you.