Minifying SQL: when it helps and when it hurts

A correct SQL minifier removes line comments starting with --, block comments between /* and */, and collapses every run of whitespace to at most one space. Around punctuation such as commas, parentheses and comparison operators the space can go away entirely, so a, b becomes a,b and x = 1 becomes x=1.

What it must never touch is the content of string literals and quoted identifiers. 'two spaces' has two spaces for a reason, and a column named "first name" would stop matching if they were squeezed. Space between two words must also stay, because selectname is not the same as select name. Some cases are subtle: a - -1 needs its spaces, since -- would start a comment. TidySQL handles single, double, backtick and bracket quotes as well as PostgreSQL dollar-quoted strings.

The best reason to minify is a container that does not handle line breaks well. Environment variables, single-line YAML or .env values, JSON strings and CSV cells all either forbid newlines or require escaping them. A command line is similar: psql -c, mysql -e and sqlite3 accept a query as one argument, and pasting a multi-line query into a shell often runs only the first line.

Minified queries are also handy for logging and monitoring. A one-line statement fits in a single log record, can be grepped, and groups correctly in tools that aggregate identical queries. Removing comments has a privacy side effect as well: notes such as ticket links or test credentials will not leak into logs or shared snippets.

Minifying a query does not make it run faster. Databases parse whitespace and comments in microseconds, and the execution plan depends only on the tokens, which minification leaves untouched. A slow query stays slow; to speed it up you need indexes, better join conditions or less data, and a readable query makes that work easier.

The bandwidth saving is also small. A few hundred bytes of indentation are irrelevant next to the result set. There is one caveat with comments: some engines use them for optimizer hints, written as /*+ ... */ in MySQL and Oracle-style tools. A minifier that strips all comments also removes those hints, so keep the original if you rely on them.

Treat the minified line as a build product, not as source code. The query in your repository, migration or documentation should stay formatted and commented, and the one-liner should be generated from it when needed. If the minified version is the only copy, the next person has to reformat it before they can change anything.

The round trip is cheap. Paste a one-liner from a log into TidySQL, press Format, fix what you need, then press Minify to put it back into the config. Because both operations only change whitespace and comments, the statement the database receives is identical either way.

A script with several statements stays valid after minification because the semicolons that separate them are kept. The whole script becomes one line with statements joined by ;, which is what tools such as mysql -e expect when you want to run a short sequence in a single call. For long migrations this is rarely a good idea, though: an error message that points to line 1, column 4,812 is much harder to act on than one that points to line 37.

A practical rule is to minify single statements or short batches that live inside another format, and to ship longer scripts as normal .sql files with line breaks. The database does not care either way, but the person reading the error log at night will.