9.7k stars · MIT · no GitHub releases; the Python package index gives 30.24.0, 20 October 2026 · Track this in Scout
Reads, rewrites and translates SQL between more than twenty database dialects, without a database.
▶Repo detailsthe review · specs · pros & cons · install
What it does
It parses a query into a tree of parts, so a program can look at the pieces instead of hunting through text. It writes that tree back out as SQL for a different system, covering more than twenty dialects including PostgreSQL, MySQL, BigQuery, Snowflake, DuckDB, Spark and Oracle. It can format a query, compare two queries for real differences rather than spacing differences, and tell you which columns in the answer came from which columns in the source. An optimiser rewrites a query into a form that usually runs faster. It is written in pure Python with no outside dependencies, which is why it installs in seconds. It is deliberately forgiving: it will parse things a real database would reject. It is not a database and not a query runner, so it cannot tell you whether a table exists, whether a query is permitted, or how long it will take.
Why it matters
Who it suits. Anyone whose code writes SQL as text and then hopes. It suits a small team that supports more than one database, because a query written once can be emitted for each. It also suits anyone who needs to know where a number in a report came from, since the column-lineage feature answers exactly that. Skip it if all SQL is typed by hand into one database and never generated by a program.
Verdict. The best thing in this edition, and ten minutes well spent. The pure-Python install with no dependencies is the reason to try it rather than read about it: there is nothing to break. It is also the clearest case of today's headline. GitHub shows no releases for this project at all, so the releases page says nothing, while the published Python package moved to version 30.24.0 on 20 October 2026 and code was pushed on 23 October. Two things to watch out for. The forgiving parser means a query can pass here and still be refused by the real database, so this is a translator and not a validator. And the dialect coverage is uneven: the common systems are excellent and the rare ones are approximate, so test the output rather than trusting it. If the need is checking style and catching mistakes in hand-written SQL instead, sqlfluff/sqlfluff from Edition 57 is the right tool, and the two are often used together.
- Pure Python with no dependencies, so it installs anywhere in seconds.
- Column lineage answers "where did this number come from", which almost nothing else does.
- Twenty-plus dialects in one library, with one way of writing the code.
- The parser accepts queries a real database will reject, so it proves nothing about validity.
- Dialect quality varies, and the less common systems need the output checked by hand.
- No releases on GitHub at all, so the version has to be read from the package registry.
sqlfluff/sqlfluffMIT, covered in Edition 57; checks hand-written SQL for style and mistakes and repairs most of them, where this one rewrites and translates queries from code.
Track this in Scout- andialbrecht/sqlparse
BSD-3-Clause, splits SQL into tokens and formats it, which is a much smaller job and a much smaller library; it does not translate between dialects.
Track this in Scout
python3 -m venv venv source venv/bin/activate pip install sqlglot
