Why this needed a real parser, not a regex pass#
A regex-based SQL "formatter" — one that just inserts a newline before every SELECT, FROM, WHERE it spots — breaks the moment those words appear somewhere they are not a clause keyword: inside a string literal, a column named from_date, or a subquery whose own clauses need a deeper indent level than the outer query's. Correctly formatting SQL means actually parsing its grammar (understanding what is a subquery, what is nested inside what, where one clause ends and the next begins) — hard enough that this tool uses a dedicated SQL parsing library instead of attempting it by hand, the same reasoning already applied to YAML on this site.
Why the dialect selector matters#
SQL isn't one language — MySQL quotes identifiers with backticks, PostgreSQL and standard SQL use double quotes, and each dialect has its own extensions and reserved words. Picking the wrong dialect can cause valid syntax to be misread or database-specific syntax to fail entirely. Match the dialect to whichever database the query is actually meant to run against.
Uppercase keywords: a convention, not a requirement#
SQL keywords are case-insensitive to every database engine — select and SELECT execute identically. Uppercasing them (the default here) is a long-standing readability convention that visually separates SQL syntax from table and column names in mixed-case queries; "preserve" mode is available for anyone who deliberately writes lowercase and wants that kept.