Its 28 dialects turn style into shared infrastructure
SQLFluff's current README lists 28 dialects, ranging from ANSI and PostgreSQL to Snowflake, BigQuery, Databricks, and T-SQL. It parses SQL before applying configurable rules, which lets it reason about aliases, joins, layout, and structure instead of treating a query as plain text. Jinja, placeholders, Python format strings, and dbt cover the template systems common in analytics repositories.
Release 4.4.0 added an optional SQLMesh templater and GitLab Code Quality output. GitHub annotations and SARIF were already available. That combination makes SQLFluff useful as a policy layer across editors and CI, especially when one company has several warehouses. The tradeoff is equally concrete: every additional grammar and template boundary creates another place where an innocent-looking format rule can misunderstand meaning.
What happened when we ran it
Our sandbox installed commit d5ae64c in 80 seconds, pulling 84 packages and occupying 165 MB. The build completed successfully in 8 seconds. Pip-audit reported 0 known vulnerabilities. We ran it in an unprivileged Debian container with Python 3.12, 3 CPUs, 8 GB of RAM, and no secrets.
Tests did not finish within the 900-second limit. The last output showed normal progress dots moving from 49% through 54%, with no failure traceback in the supplied tail. The correct result is a timeout, not a failed suite and not a pass. We cannot say how long the remaining tests would have taken or whether a later test would have failed.
The checkout itself was substantial: 6,087 files, about 220,773 lines of source, and 26.1 MB before dependencies. It had 15 CI workflow files, a Dockerfile, a compose file, and a tests directory. Installing and building are reasonable on a small runner. Running the complete contributor checks needs more than the 15 minutes our sandbox allowed.
Automatic fixes belong behind a reviewed diff
Lint findings are the low-risk entry point because a developer can judge the warning before changing a query. sqlfluff fix deserves a stricter gate. Open issue 8626 shows RF03 removing qualifiers inside a T-SQL APPLY subquery. The reported predicate changed from a correlated comparison to patientid = patientid, which stays valid SQL while becoming true for non-null values.
Issue 8611 is more direct. On SQLFluff 4.3.0, several layout fixes deleted source text when an identifier crossed a Jinja tag. The command reported the file as fixed and exited 0 in the supplied reproductions. Version 4.4.0 includes many fixes, but its release notes do not identify that open report as resolved. Run fixes on a branch, inspect semantic changes, and execute warehouse-specific tests before merging.
Templates and the Rust parser add separate compatibility edges
The default Python route installs with pip install sqlfluff. dbt support requires its plugin, and 4.4.0 gives SQLMesh its own optional templater. Template rendering is part of correctness because SQLFluff must map generated SQL back to source files. Issue 8624 also reports two default layout rules alternating forever on an overlength single-target SELECT, reproducing the loop across 7 dialects.
The optional rs extra can speed parser work through a prebuilt ABI3 wheel on supported CPython 3.10+ systems. An unsupported platform falls back to a source build and therefore needs Rust plus C or C++ tools. Open issue 8612 documents a Databricks grammar case where the Python and Rust parsers produce different results. Test the parser choice against your own dialect fixtures before standardizing it in CI.
Narrower tools win when formatting is the whole policy
sqruff is a Rust linter and formatter with its own language server plus VS Code and Zed integrations. It is the closest alternative when teams want lint rules and editor feedback without adopting SQLFluff's Python and templater stack. Check its dialect and rule coverage against your project first, since portability does not replace the grammar you need.
SQL Formatter confines itself to whitespace formatting across several query languages, while pgFormatter concentrates on PostgreSQL syntax. Either can be easier to explain in a repository that only wants consistent layout. SQLFluff earns its larger 165 MB installed environment when 28 dialects, rendered templates, structural rules, and CI annotations are requirements rather than future possibilities.
A one-day-old release and same-day push show active maintenance
Version 4.4.0 shipped on October 2, 2026, and the repository was pushed again on October 3. GitHub showed 9,914 stars and 351 combined open issues and pull requests. The release added SQLMesh support, GitLab output, custom Jinja delimiters, and fixes across several dialects. A large open queue is unsurprising for 28 grammars, but it makes issue search part of an upgrade review.
Start by pinning the dialect, selecting a small rule set, and running lint without fixes. Add template plugins only where the source actually uses them. Once warnings match the team's intent, introduce reviewed fixes and regression queries for business-critical SQL. SQLFluff earns the operational work when one rule system replaces several warehouse-specific checks. A formatting-only repository can avoid the 165 MB environment and 900-second contributor-suite concern with a narrower tool.