SQL Formatting Best Practices for 2026: Standards That Actually Work

There's no single SQL style guide everyone agrees on. The Mozilla style guide says one thing, the GitLab data team says another, and the dbt community has a third opinion. But after comparing all of them, about a dozen rules survive across every guide — and those are the ones that actually matter.

The Rules That Matter

Uppercase keywords (SELECT, FROM, WHERE), lowercase identifiers. Pick 2 or 4 space indent and stick to it. Put each major clause on its own line. Stack WHERE conditions vertically with AND/OR at the start of each line. Use trailing commas (the dominant convention in 2026). Keep columns on separate lines for queries over 3 lines. Apply these rules with an auto-formatter — hand-formatting SQL is a waste of time. Use sqlfluff in CI for enforcement.

Why This Matters in 2026

SQL remains the standard query language for relational databases, and writing clean, well-formatted SQL is essential for maintainable data pipelines. In 2026, the diversity of SQL dialects — PostgreSQL, MySQL, Oracle, SQL Server, BigQuery — makes formatting more challenging, as each dialect has unique keywords and syntax. Consistent SQL formatting makes code reviews faster, diffs cleaner, and debugging easier. With tools like sqlfluff for linting and modern formatters supporting 13+ dialects, there is no excuse for poorly formatted SQL.

Key Takeaways

• Uppercase keywords (SELECT, FROM, WHERE) for readability and convention
• Use 2 or 4 space indentation consistently — never mix the two
• Put each major clause on its own line for queries over 3 lines
• Use trailing commas — the dominant convention in 2026
• Stack WHERE conditions vertically with AND/OR at the start of each line
• Always select the correct dialect before formatting — generic ANSI breaks dialect-specific syntax

Common Mistakes to Avoid

• Using lowercase keywords — inconsistent and harder to scan
• Mixing 2-space and 4-space indentation within the same file
• Putting all columns on one line for long queries — unreadable
• Not selecting the correct SQL dialect before formatting, breaking dialect-specific syntax
• Using leading commas instead of trailing commas — inconsistent with 2026 conventions
• Not enforcing formatting with a linter in CI, leading to inconsistent styles across the team

Best Practices

• Uppercase keywords, lowercase identifiers — the universal convention
• Pick 2 or 4 space indent and enforce it with a formatter
• One column per line for queries over 3 lines
• Use trailing commas — dominant in 2026 data teams
• Enforce with sqlfluff in CI — auto-fix formatting issues
• Document your SQL style guide in the repo for team alignment

Quick Reference

Here is a quick reference for well-formatted SQL following the dominant 2026 conventions:

SELECT
    u.id,
    u.name,
    u.email,
    COUNT(o.id) AS order_count,
    SUM(o.total) AS total_spent,
FROM users AS u
LEFT JOIN orders AS o
    ON u.id = o.user_id
WHERE u.created_at >= "2026-01-01"
    AND u.status = "active"
GROUP BY
    u.id,
    u.name,
    u.email,
HAVING COUNT(o.id) > 0
ORDER BY total_spent DESC
LIMIT 20;

Real-World Example

A practical example: a reporting query that joins multiple tables with proper formatting. This pattern is used in analytics dashboards and data pipelines:

WITH monthly_revenue AS (
    SELECT
        DATE_TRUNC("month", created_at) AS month,
        SUM(total) AS revenue,
        COUNT(*) AS order_count,
    FROM orders
    WHERE status = "completed"
    GROUP BY DATE_TRUNC("month", created_at)
)
SELECT
    month,
    revenue,
    order_count,
    ROUND(revenue / NULLIF(order_count, 0), 2) AS avg_order_value,
FROM monthly_revenue
ORDER BY month DESC;

Tools and Resources

• DevKit SQL Formatter — format SQL across 13+ dialects in the browser
• sqlfluff — SQL linter with auto-fix for CI pipelines
• pgFormatter — PostgreSQL-specific formatter and beautifier
• SQLFluff Studio — VS Code extension for real-time SQL formatting
• DataGrip — JetBrains IDE with built-in SQL formatting and dialect support

"SQL is the English of data. Everyone speaks it, but few speak it well. Formatting is the difference between a query and a work of art."

Clean SQL formatting makes code reviews faster, diffs cleaner, and debugging easier. Uppercase keywords, use consistent indentation, put each column on its own line, and enforce conventions with sqlfluff in CI. Always select the correct dialect before formatting to avoid breaking dialect-specific syntax.