Top SQL Review Tools in 2026: From Linting to Governance

SQL review is the automated check of SQL changes (schema migrations and data operations) against a set of rules before the SQL runs against a database. It sits between SQL linting, which only sees syntax and style, and code review, which is a human reading a pull request. The tools that call themselves "SQL review tools" or "SQL lint tools" do very different amounts of that work, and the quickest way to sort them is by layer: style, semantics, or policy. The confusion in the market comes from the fact that a layer 1 tool and a layer 3 tool both answer "do you do SQL review?" with "yes." This list goes through the cross-engine tools in that order. The linters that exist for only one database are named at the end of layer 2 and covered in the per-engine lists.

What we looked at#

• Layer. Does the tool check style (layer 1), understand what the SQL does to the database (layer 2), or decide whether the change may run in a given environment and who approves it (layer 3)?
• Engines. How many dialects, and whether the rules are engine-aware or generic.
• Where it runs. CLI, CI, IDE, a web workflow, an API.
• Rules. The shipped count, and whether per-environment policy exists (warn in dev, block in prod).
• Licence and price. What is open source, what is gated to a paid tier.
• Approval. Whether a human sign-off lives inside the review or has to be stitched on from the pull request.

Layer 1: linters#

A linter checks syntax correctness and style conventions: keyword casing, indentation, aliasing, forbidden functions. It is Prettier or ESLint for SQL. It prevents style arguments in code review, and it does not know what the SQL does.

SQLFluff#

SQLFluff is the default answer to "best SQL lint tool," and the one the other tools build on. Version 4.4.0 (October 2026) ships 79 rules in 11 bundles (aliasing, ambiguous, capitalisation, convention, layout, references, structure, plus small Jinja, Postgres, Oracle, and T-SQL sets) across 28 dialects from ANSI to Vertica. MIT licence, about 10,000 GitHub stars. The Jinja templater is why it owns the analytics world: dbt's platform runs SQLFluff for linting and formatting, and dbt Core has no linter of its own.

The thing to know before adopting it: a 79-rule config is a negotiation. Expect to disable a third of the layout rules in week one. Keep the aliasing and references bundles. That is where the real catches are: unqualified column references in joins, ambiguous DISTINCT with GROUP BY.

Best for: any team that wants one linter across warehouses and OLTP databases, and anyone on dbt.

Sqruff#

Sqruff is a SQL linter and formatter written in Rust, Apache-2.0, at v0.42 (October 2026) with about 1,400 stars. It targets the same job as SQLFluff with a compatible rule layout and config file, and it exists because SQLFluff is slow on large repositories: Python plus a full parse per file. Sqruff covers 27 dialects, including Postgres, MySQL, T-SQL, Oracle, Snowflake, BigQuery, ClickHouse, and DuckDB.

Best for: a monorepo where SQLFluff has become the slowest CI step. Check your dialect first; the long tail is thinner than SQLFluff's.

SonarQube (T-SQL and PL/SQL)#

SonarQube analyzes T-SQL and PL/SQL as code-quality languages in its Developer Edition and above, surfacing bugs, vulnerabilities, and code smells in the same dashboard as the application code. The rules are source-level (unused variables, dead code, risky dynamic SQL), not database-aware, and there is no per-environment concept.

Best for: teams already on SonarQube that want stored-procedure code held to the same gate as Java or C#.

Redgate SQL Prompt code analysis#

Redgate's code analysis rules live in SQL Prompt, inside SSMS and Visual Studio. T-SQL only, with rule families for best practice, deprecated syntax, execution, naming, performance, and style, each with a prefix code like ST002. Its reach comes from running where SQL Server DBAs already type.

Best for: SQL Server shops; it is a style and hygiene layer, not a migration-safety one.

Layer 2: semantic rules#

Layer 2 rules understand the database. A missing primary key, an ALTER TABLE that rewrites a large table while holding a lock, a DELETE with no WHERE, a foreign key column with no index: none of these are syntax errors, and all of them hurt in production. Most of Bytebase's rule set lives at this layer too; it is listed under layer 3 below because of what it adds on top of the rules.

Squawk#

Squawk is a linter for Postgres migrations, Apache-2.0, v2.70 (October 2026), 78 rules. The rules are about locks and compatibility, not style: require-concurrent-index-creation, adding-required-field, ban-drop-column, prefer-bigint-over-int, require-lock-timeout, constraint-missing-not-valid. It runs as a CLI or a GitHub Action, and can post its findings as a comment on the pull request from CI.

Squawk is the tool that catches the migration that pages someone at 2am. It is also Postgres-only, and it does not know your environment: the same rule fires on a 10-row dev table and a 400-million-row production one.

Best for: Postgres teams running migrations through CI with nothing else in place yet.

sqlcheck#

sqlcheck detects anti-patterns in SQL text: logical design (multi-valued columns, entity-attribute-value), physical design (too many indexes, floating-point money), query patterns (SELECT *, implicit columns, ORDER BY RAND()), and application patterns. Apache-2.0, about 2,500 stars, with a --risk_level switch to limit output to medium and high risks. The last release is v1.3 from March 2022, and the repository has been quiet since early 2024.

Best for: a one-off audit of an inherited codebase. Do not build a CI gate on it; the rule set is frozen.

Liquibase Policy Checks#

Liquibase Secure (the commercial edition; Community has no checks) runs Policy Checks against changelogs, SQL, and the live database. Secure 6.0 (September 2026) moved them into a visual policy centre with more than 50 prebuilt rules, reusable policy packages per application and environment, and custom checks in Python or regex. Severity sets an exit code, so a CI pipeline can block on them. Since 5.1, a prebuilt check flags personal or health data inside INSERT and UPDATE statements.

Best for: teams already on Liquibase whose changes are changelogs rather than raw SQL files; the checks understand changeset structure in a way a generic linter cannot.

Flyway code analysis#

Flyway's check -code works in two tiers. Community integrates with a locally installed SQLFluff, so you get the 79 rules above with Flyway's file discovery. Enterprise adds Redgate's own rules aimed at data loss and security (SQLFluff-based RG rules and regex-based RX rules such as RX001 for DROP TABLE), lets you write your own regex rules, and can halt the CI pipeline on violations.

Best for: Flyway shops that want the check in the same command as the migration. Community runs your local SQLFluff; the Redgate rules are Enterprise.

The engine-specific tools#

Some of the best layer-2 tools exist for exactly one database and are covered in the per-engine lists: plpgsql_check and pgTAP for Postgres; Skeema, SOAR, and pt-duplicate-key-checker for MySQL; SQL Database Projects analysis, SqlServer.Rules, and tSQLt for SQL Server; SQLcl CODESCAN, dbLinter, and PL/SQL compiler warnings for Oracle.

Layer 3: policy and approval#

Layer 3 is where governance starts. The same rule warns in dev and blocks in prod, the result is shown to the person who approves the change, and the approval is recorded with the SQL. Only one tool on this list does all three.

Bytebase#

Bytebase runs SQL Review with 200+ engine-specific rules on every tier, including the free Community edition. The rules span layer 1 (naming conventions, identifier case, comment requirements; it does not format SQL the way SQLFluff does) and layer 2 (primary keys, DELETE without WHERE, indexes on foreign keys, non-additive schema changes), and they are configured as a per-environment review policy. Layer 3 starts there. Lint rules cover MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, TiDB, OceanBase, and Snowflake. The same engine runs in three places: inline in the change issue a developer opens, as a check on pull requests in GitHub or GitLab through the GitOps workflow, and over the REST API.

The part the other tools do not have is what happens after the rule fires. In Bytebase the review result, the environment policy, and the approval flow sit on the same issue, so the approver sees "non-additive change, blocked in prod" next to the ALTER TABLE and the rollout record follows. On the other tools here, the result is a CI exit code or a PR comment, and the approval happens outside the tool.

Bytebase is open source under MIT with Enterprise features under a commercial licence; approval workflows and risk-based routing are Enterprise, the rules themselves are not.

Best for: teams that need a human sign-off on production DDL and want the rule results in front of that human, across more than one engine.

Manual DBA review#

Still the default layer-3 tool: a DBA reads the script in an email or a ticket. It has per-environment judgment and a real approval, and no rule count, no consistency, and no record beyond the thread.

Comparison#

Which to pick#

The three questions people actually search for have three different answers.

Best standalone SQL lint tool: SQLFluff. Reach for Sqruff only when SQLFluff's runtime is the problem, and keep the SQLFluff config so you can move back.

Linting plus anti-pattern detection: on Postgres, SQLFluff for style and Squawk for migrations, both in CI, both commenting on the PR. On other engines, pair SQLFluff with the engine-specific tool from the per-engine list; sqlcheck is a read-once audit, not a gate.

Automated SQL review for CI/CD pipelines: if you already deploy with Liquibase Secure or Flyway Enterprise, turn their checks on; they understand your changelogs and migrations better than a generic linter will. If the problem is that a human still has to approve production DDL and nobody can see the lint result when they do, that is layer 3, and Bytebase is the tool on this list built for it. In the teams we work with, that is usually the reason Bytebase ends up in the stack next to an existing SQLFluff job, not instead of it.