SQL Style Guide: Uppercase Keywords, Indentation, and Team Conventions

Consistent SQL formatting makes code reviews faster, diffs cleaner, and debugging easier. But getting a team to agree on conventions and actually follow them requires the right combination of rules and tooling. Too many rules and people ignore them; too few and the formatting is inconsistent.

Setting Up Team Conventions

Start with the basics: uppercase keywords, 2 or 4 space indent, trailing commas, one column per line. Document the rules in a SQL style guide in your repo. Enforce with sqlfluff in CI — it auto-fixes formatting issues and flags violations. Configure the formatter to match your team's preferences: keyword case, indent width, comma position, and AND/OR placement. Don't over-customize — the default rules from popular style guides are good enough for most teams. Consistency matters more than the specific rules chosen.

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.