Why SQL dialect matters for formatting
Postgres, MySQL, BigQuery, Snowflake, Redshift, SQLite, and T-SQL share the same core SQL grammar but diverge on quoting rules, reserved keywords, and dialect-specific syntax (BigQuery’s backtick-quoted identifiers, T-SQL’s square-bracket identifiers, and so on). Formatting with the wrong dialect assumed can misplace tokens around syntax the formatter doesn’t recognise — selecting your actual database’s dialect keeps the output correct as well as pretty.
Reading long queries is a real productivity cost
A 200-line query with inconsistent indentation and no keyword casing convention is slow to review and easy to introduce a bug into during an edit. Consistent formatting — aligned clauses, uniform keyword case, predictable indentation — makes it much faster to spot a missing JOIN condition or a misplaced WHERE clause during review.
Keyword case: a team style choice
Some teams write SQL keywords in UPPERCASEto visually separate them from column and table names; others prefer lowercase for a less shouty style. Neither is more “correct” — the formatter supports both so the output matches your team’s existing SQL style guide.
Why use UtilityApps for this
Formatting happens entirely in your browser with no signup — your queries (which may reference internal table or column names) are never uploaded to a server.