SQL Formatters Compared: sqlparse vs SQLFluff vs pg_format vs Database-Native Tools

"Format my SQL" means four different jobs: pretty-print it, lint it for style violations, normalize it for diffs, or just line-wrap it. Tools market themselves as interchangeable; they aren't. Here's the map, with the honest weaknesses each camp leaves out of its readme.

sqlparse (Python library, not a tool)

import sqlparse
print(sqlparse.format(sql, strip_comments=False))

• Wins: installed with half the Python data stack, zero-config, in-process formatting for notebooks and migration scripts. It's token-based, so it survives dialect weirdness that regex formatters choke on.
• Losers: the output is conservative to the point of shyness — alignment is minimal, CTE structure stays flat, and its "keywords" list shows its age on window functions and modern JSON operators. You will still hand-fix its output on complex queries.
• Honest take: the right dependency for programs that format SQL incidentally. Not the answer to "make this reviewable."

SQLFluff (the linter that formats)

sqlfluff lint query.sql --dialect postgres
sqlfluff fix query.sql --dialect postgres

• Wins: the only serious lint story: dialect-aware parsing (postgres, mysql, tsql, snowflake, bigquery), rules you can enforce in CI (L044: no SELECT *, ambiguous-column rules), and fix that rewrites violations. If SQL is product code, SQLFluff in pre-commit is the strongest choice on this page.
• Losers: it's a linter — setup is a config file and a rule policy, parse failures on exotic syntax become CI red you must triage, and its "fixes" change style semantically-verified but not semantically-changed, which means review noise the first week. It's also slow enough on a large repo that you'll scope it to changed files.
• Honest take: format-on-merge with rules; use a quick beautifier for the interactive read-paste-debug loop where SQLFluff's ceremony doesn't fit. See when to use which below.

pg_format / pgFormatter (the Postgres parsers)

pg_format (the C library behind psql's own --pset tricks and the popular CLI) and its PHP ancestor pgFormatter both run the input through Postgres' real grammar.

• Wins: correctness by construction — it can't mangle what it parsed with the server's own parser, and it handles Postgres-specific syntax (:: casts, ARRAY[...], LATERAL, JSONB operators) that generic formatters flatten incorrectly.
• Losers: Postgres-only, obviously — feed it T-SQL and you get garbage or an error. And it reformats aggressively: your hand-placed alignment gets opinions applied to it, which is either the point or the dealbreaker depending on the team.
• Honest take: the gold standard within its dialect. This site's Postgres route targets the same syntax set browser-side with no libpq; pg_format remains the right pick inside a Postgres-native toolchain.

Database-native: the psql expand trick and vendor CLIs

psql has \pset expanded auto for wide single-row output. SQL Developer ships a beautifier, and SSMS finally grew a native SQL Formatter — preview in 22.7, generally available by late 2026, with format-on-demand, format-on-save, and .editorconfig control.

• Wins: free, inside the client you're already using, and vendor-accurate by definition. The SSMS formatter in particular closes the most common reason people pasted production queries into a random website: through most of SSMS's life there was no built-in formatting whatsoever, which is the case for a local tool told in one anecdote.
• Losers: locked to the vendor and usually locked to the GUI. Each one formats one dialect, they don't share a style policy with the rest of your repo, and "format on save" inside a client is not a CI gate. A formatter that only runs on one person's laptop is a preference, not a standard.
• Honest take: use them; don't standardize a polyglot team on them. The vendor formatter covers your day-to-day in one engine; the repo-wide rule still has to live somewhere engine-neutral.

Browser formatters (including this site)

• Wins: paste → readable in the same keystroke; zero install matters most exactly when you don't control the machine (bastion host, locked-down laptop); client-side processing means production query text doesn't transit a third-party server — audit that claim on any formatter you use, including this one (check the network tab).
• Losers: not scriptable, no rule policy, no CI. A beautifier is a reading tool; SQLFluff is a policy tool.
• Honest take: the formatter belongs in the debug loop; SQLFluff belongs in the merge gate; both belong in your workflow because they're different jobs. Our minifier route covers the third job — collapsing queries for embedding — that none of the above do well.

Comparison table

FAQ

Which one should my team standardize on? SQLFluff for the repo (policy), a beautifier for the REPL loop (reading). One tool per job beats one tool for both jobs.

Can a formatter change my query's meaning? A correct one can't — whitespace-only transformations. The real risk is comment placement (inline -- comments swallowing the rest of a minified line) and quoted-case identifiers. That's why gotchas exists.

Why is my window function still on one line? Some formatters treat a long OVER (...) as an opaque expression. SQLFluff and pg_format unwrap them; most regex-formatters don't. If it matters, check with one windowed query before adopting any tool.