Formatting SQL Across 13 Dialects: PostgreSQL, MySQL, Oracle, and More

SQL isn't one language — every database has its own keywords, functions, and quoting rules. A formatter that doesn't understand your dialect will mangle dialect-specific syntax. In 2026, modern SQL formatters support 11-13 dialects, each with dedicated grammar rules.

Dialect-Specific Formatting

PostgreSQL: handles ARRAY, JSON, RETURNING, :: cast syntax. T-SQL (SQL Server): handles TOP, OUTPUT, CROSS APPLY, @variables. PL/SQL (Oracle): handles BEGIN/EXCEPTION/END, explicit cursors. BigQuery: handles STRUCT, ARRAY_AGG, EXCEPT clause. MySQL: handles stored procedure DELIMITER changes. Always select the correct dialect before formatting — a generic ANSI SQL parser will break dialect-specific constructs. Use a formatter that supports your specific database engine.

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.