September 28, 2026
Why SQL Formatters Can't Always Preserve Your Query's Meaning
A SQL formatter reformats whitespace, capitalization, and line breaks — it does not change the query's logic, so in the overwhelming majority of cases reformatting is completely safe. The real risk is narrower than "formatting breaks queries": specific constructs like inline optimizer hints, dialect-specific syntax, and comment placement are where an aggressive formatter can produce output that still runs but no longer means what you intended.

Optimizer hints are the sharpest edge
Oracle's /*+ INDEX(t idx_name) */ and MySQL's /*+ USE_INDEX(t idx_name) */ syntax look like ordinary comments to a formatter that isn't specifically dialect-aware — because syntactically, they are comments; the engine only treats the content specially due to the leading +. A formatter that strips, reorders, or relocates comments as part of cleanup can silently remove a hint that was there to fix a specific slow-query problem, with no error and no obvious symptom until performance regresses again.
Dialect differences matter more than most formatters admit
- Backtick-quoted identifiers (MySQL) vs. double-quoted (Postgres/standard SQL) vs. bracketed (SQL Server) — a formatter defaulting to the wrong dialect's quoting can produce syntactically invalid output for your actual database
- T-SQL's square-bracket [Table Name] syntax has no direct standard-SQL equivalent
- Reserved word lists differ by dialect — a column name that's safe in Postgres might need escaping in MySQL, and a formatter unaware of the target dialect won't know to add it
What's actually safe to trust a formatter with
Whitespace, indentation, keyword capitalization, and line breaks around clauses (SELECT, FROM, WHERE, JOIN) — none of this affects execution, and this is what the overwhelming majority of formatting requests actually are. The rule of thumb: pick a formatter that lets you select the correct SQL dialect explicitly rather than guessing, and treat any query containing inline hints or comments as worth a manual diff-check after formatting, not a blind trust-and-run.
Want to try this yourself?
Open SQL Formatter →