# Top SQL Server SQL Review Tools in 2026

> SQL Server SQL review tools compared: the built-in SR rules in SQL projects, SqlServer.Rules' 140+ T-SQL checks, SQLFluff, tSQLt, Redgate, and where Bytebase's approval gate fits.

Adela | 2026-09-02 | Source: https://www.bytebase.com/blog/top-sql-server-sql-review-tools/

---

> **Note:** This post is maintained by Bytebase, an open-source database governance platform. We update the post periodically.

SQL Server's review tooling is shaped differently from MySQL's or Postgres's, and not because T-SQL needs less of it. Microsoft ships static analysis inside its own build toolchain, so the baseline is free, first-party, and already installed for anyone using a SQL project. The strongest community option extends that same rule model rather than competing with it. What's thin is everything in between: fewer independent open source linters than Postgres has, and two names that still show up in every "SQL Server SQL review" search stopped shipping entirely.

What are the criteria? Every pick here is:

- **T-SQL-aware** - general SQL linters that treat T-SQL as an afterthought are noted, but the picks below either target SQL Server specifically or have real T-SQL dialect coverage.
- **Actively maintained, or the gap disclosed if not** - checked against commit and release history, not a marketing page. One pick below has not cut a release since 2022, and that is stated in its own section rather than buried. The tools that fail the check outright are named below as failures, not recommendations.
- **Adoptable on its own** - no pick requires the others to be useful.

## Built-in SQL code analysis (SQL Database Projects)

If your schema lives in a SQL project, you already have a linter and it is off by default. SQL Database Projects ship 14 rules under `Microsoft.Rules.Data`, split across the same three categories every other tool on this list uses: design, naming, and performance. It applies to projects targeting SQL Server, Azure SQL Database, Azure SQL Managed Instance, and Fabric SQL database.

The design rules are the ones worth turning on first. `SR0001` flags `SELECT *` in stored procedures, views, and table-valued functions. `SR0008` catches `@@IDENTITY` where `SCOPE_IDENTITY` is almost always what you meant, which is a correctness bug that only shows up once a trigger exists. `SR0013` finds an output parameter that isn't populated on every code path. `SR0010` catches the deprecated `*=` join syntax. On the naming side, `SR0016` is the `sp_` prefix rule — SQL Server checks the master database first for any procedure named that way, no matter how you qualify it. On performance, `SR0005` flags a `LIKE` pattern starting with `%`, and `SR0004` an unindexed column as the test expression in an `IN` predicate.

Enabling it is a project property, and a rule can be disabled with `-` or promoted from warning to error with `+!`:

```xml
<PropertyGroup>
  <RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>
  <SqlCodeAnalysisRules>-Microsoft.Rules.Data.SR0006;+!Microsoft.Rules.Data.SR0008</SqlCodeAnalysisRules>
</PropertyGroup>
```

The same settings override from CI with `dotnet build /p:RunSqlCodeAnalysis=True`, and per-file exceptions go in a `StaticCodeAnalysis.SuppressMessages.xml` rather than a comment someone deletes later. Configuration used to mean hand-editing the `.sqlproj`; the VS Code SQL Database Projects extension added a Code Analysis Settings dialog in 2026, with per-category toggles and a Warning/Error/None dropdown per rule. SSMS and Visual Studio expose the same thing under project properties.

Two limits. It analyzes the project model, so a script you're about to run by hand isn't covered — only what's in the project. And 14 rules is a floor: nothing here knows about locking or migration safety, the performance rules stop at a handful of predicate patterns, and there's no index-hygiene coverage at all.

**Best for:** any team already building a SQL project. It's one property away, and there's no reason to leave it off.

## SqlServer.Rules and T-SQL Analyzer

[SqlServer.Rules](https://github.com/ErikEJ/SqlServer.Rules) is the same idea at roughly ten times the coverage: 140+ rules, MIT-licensed, built on the same code-analysis extensibility model Microsoft's 14 rules use. It re-covers the built-in basics and keeps going — `SRD0002` for a missing primary key, `SRD0004` for a foreign key with no supporting index, `SRD0003` for a primary key that's too wide, `SRP0001` for views stacked on views, `SRN0006` for two-part object naming.

The 2026 change is where it runs. This used to be a build-time NuGet package and nothing else. It now also ships as the T-SQL Analyzer extension, which analyzes plain `.sql` files live in the editor — stored procedures, queries, migration scripts, ad-hoc SQL — with no build step and no SQL project required. Visual Studio and SSMS 22 got it in June 2026, VS Code in August 2026. Rules are configured with the same expression syntax Microsoft's MSBuild property uses (`-SqlServer.Rules.SRD0004` to disable, `+!SqlServer.Rules.SRN0005` to promote to error), and `tsqlAnalyzer.sqlVersion` pins the target version — `Sql160`, `Sql170`, `SqlAzure` — so the analysis matches the server you actually deploy to. There's also a CLI and an MCP server for driving the same rules from GitHub Copilot.

The build-time package, `ErikEJ.DacFX.SqlServer.Rules`, is still there and works with `MSBuild.Sdk.SqlProj`, `Microsoft.Build.Sql`, and classic `.sqlproj` projects alike, so adopting it doesn't force a project conversion first.

What it can't do is look at your data. The foreign-key index rule and its neighbors are static heuristics against the statement and the model; the analyzer doesn't know your row counts or index statistics, so the same finding on a 200-row lookup table is noise you'll want to suppress. Worth knowing too: it's a single-maintainer community project, forked from an earlier one, and the whole 140-rule set rests on that.

**Best for:** the deepest T-SQL-specific coverage available, free, whether your SQL lives in a project or in loose scripts.

## SQLFluff (T-SQL dialect)

[SQLFluff](https://sqlfluff.com/) is a style linter, not a safety linter, and it's the only pick here that treats SQL as text rather than as a database model. It parses casing, indentation, and formatting against the `tsql` dialect and enforces one house style in CI. Its dialect coverage is real but not complete: the cast-style rule, for one, only handles the two-argument form of `CONVERT`, because T-SQL's three-argument version — the one that takes a style code — has no `CAST` equivalent to rewrite into.

Because it never builds a model of the database, it has no idea that a stored procedure calls another stored procedure, or that a view sits on top of three other views. Style and structural safety are different layers, and SQLFluff only covers the first.

**Best for:** enforcing one SQL style across a team, in CI, before it ever reaches a human reviewer.

## tSQLt

[tSQLt](https://tsqlt.org/) is a testing framework, not a linter, and belongs on this list for the same reason pgTAP does on the Postgres one. Instead of flagging a statement as risky, you write test procedures with `tSQLt.AssertEquals`, `tSQLt.ExpectException`, and similar assertions, and run them against the schema the way you'd run unit tests against application code. It runs entirely inside SQL Server via T-SQL, tests execute in a transaction that rolls back automatically, and output comes in plain text or XML for CI. It's Apache-2.0.

The maintenance picture needs stating plainly, because it's the one pick here that doesn't cleanly pass the criterion above. The last published release, V1.0.8043.39707, is from August 2022 — four years ago. The repository still sees commits, most recently in 2026, and the framework works fine on current SQL Server versions. But a project that commits without releasing is one where you're choosing between a four-year-old build and a source checkout, and that's worth knowing before you make it part of your pipeline.

Where it still earns its place: proving a migration produced the schema you intended, not just that it applied without an error. A migration that silently skips a step because of a typo'd table name passes every linter on this list and fails the first tSQLt assertion that checks for the column.

**Best for:** schema changes complex enough that "it ran without an error" isn't proof it's correct.

## Redgate SQL Prompt (SQL Code Analysis)

[Redgate SQL Prompt](https://www.red-gate.com/products/sql-prompt/) bundles a static analysis feature called SQL Code Analysis, covering best-practice, deprecated-syntax, naming, performance, and style rule categories, checked as you type in SSMS or Visual Studio. The history is worth naming: this used to be a separate free tool, SQL Code Guard, distributed as its own SSMS add-in. [Redgate deprecated the standalone add-in and folded its rule set into SQL Prompt](https://documentation.red-gate.com/scg/sql-code-analysis-documentation/sql-code-guard-ssms-2016-add-in-deprecated) — the free, unbundled version is gone, and the functionality now requires the SQL Prompt license.

That's IDE-integrated linting, not a CI gate on its own. Running it unattended against a pull request means scripting the command-line analysis path Redgate ships alongside it, rather than relying on the interactive SSMS experience.

**Best for:** teams already on SQL Prompt for autocomplete and formatting who want the linting layer included rather than a second tool.

## Tools you'll see recommended and shouldn't rely on

**ApexSQL Complete and ApexSQL Refactor are discontinued.** Quest — which owns the ApexSQL line — ended support for both on December 31, 2025, along with the ApexSQL Fundamentals Toolkit that packaged them, and is [steering existing customers to Toad for SQL Server](https://support.quest.com/product-notification/noti-00001585) instead. Refactor had already stopped being freely updated years earlier, when new versions started requiring a Toolkit license. If either still shows up in a "best SQL Server tools" list dated 2026, that list hasn't been rechecked.

**SonarQube's dedicated T-SQL plugin has been dead longer than that.** SonarSource's own SonarTSQL plugin was last updated in May 2019 and is formally deprecated. The community successor, [gretard/sonar-sql-plugin](https://github.com/gretard/sonar-sql-plugin), covers T-SQL alongside MySQL, Postgres, Snowflake, and Vertica, but its last tagged release was February 2024. SonarQube Developer Edition and above now ships built-in T-SQL analysis directly, which is the path to take if T-SQL needs to land in the same Sonar dashboard as everything else; the standalone plugin route is the one to skip.

## Bytebase

[Bytebase](https://www.bytebase.com/sql-review/) is where many teams end up putting the review itself, because one rule engine and approval workflow covers MySQL, Postgres, SQL Server, and 20+ other engines from a single console, rather than a different tool per engine.

Where this is honest rather than uniform: the [published rule library](https://docs.bytebase.com/sql-review/review-rules) documents 80+ MySQL-specific and 50+ Postgres-specific rules by name. SQL Server runs through the same review-and-approval workflow — connect an instance, attach a review policy scoped to an environment or project, and every change routes through the same issue a DBA approves — but the SQL-Server-tagged rule set isn't published at that granularity. Rule levels attach to an environment or a project, with the project-level policy taking priority, so the same rule can warn in dev and block in prod. It also runs as a [GitHub check](/blog/integrate-sql-review-into-github/) if you'd rather keep the gate in the pull request.

The practical split on SQL Server: T-SQL Analyzer gives you 140+ engine-specific checks and no opinion about who's allowed to run the change; Bytebase answers the second question and doesn't currently match the first. Run both.

**Best for:** teams that want one approval workflow across SQL Server and their other engines, paired with a dedicated T-SQL linter for anti-pattern depth.

## Comparison

| Tool | Layer | Scope | Status (2026) | License |
| --- | --- | --- | --- | --- |
| Built-in SQL code analysis | Design + naming + perf lint | SQL project (build) | 14 rules, ships with the tooling | Free with the tooling |
| SqlServer.Rules / T-SQL Analyzer | Design + naming + perf lint | `.sql` files or project | 140+ rules, live in-editor since 2026 | Open source (MIT) |
| SQLFluff (tsql) | Style | SQL text | Monthly releases | Open source (MIT) |
| tSQLt | Testing | Schema assertions | Last release Aug 2022, commits in 2026 | Open source (Apache-2.0) |
| Redgate SQL Prompt | Style + best-practice lint | SQL text (IDE) | Commercial release | Commercial |
| Bytebase | Policy + approval workflow | Change workflow | One engine across 20+ databases | Free (Community) / paid tiers |

Read the table by what's missing from your stack, not by which row lists the most rules. A team on the built-in 14 rules has a floor and no depth. A team on T-SQL Analyzer has strong static coverage and no approval gate. A team on Bytebase alone has the gate and a thinner T-SQL rule set than a dedicated linter. These stack; they don't compete.

## Picking one

Turn on the built-in code analysis first. If you build a SQL project, it costs one property and catches the `@@IDENTITY` and `SELECT *` class of problem today. Then add T-SQL Analyzer, which is the single highest-value pick on this list: free, 140+ T-SQL rules, and since 2026 it works on loose `.sql` files in the editor, so it no longer matters whether your schema is in a project at all.

SQLFluff is the next add if style consistency is the recurring code-review argument, and it's nearly free to turn on. tSQLt is a narrower bet with a real caveat: reach for it when a migration's correctness matters more than whether it merely avoided an error, and go in knowing the last release is from 2022. Redgate SQL Prompt makes sense for shops already paying for it. Skip ApexSQL Complete/Refactor and the standalone SonarQube T-SQL plugin no matter how often they still turn up in search results.

Bytebase is the layer to add once the question shifts from "is this SQL safe" to "who approved it before it ran." On SQL Server that's a pairing, not a replacement — the linters own the anti-patterns, Bytebase owns the gate and the audit trail.

For the three-layer framework this list assumes — linting, semantic rules, policy — [SQL review: from linting to governance](/blog/sql-review-tool-for-devs/) is the place to start. The same comparison exists for [MySQL](/blog/top-mysql-sql-review-tools/) and [Postgres](/blog/top-postgres-sql-review-tools/) if you run a mixed estate.

## Related reading

- [Top MySQL SQL Review and Lint Tools in 2026](https://www.bytebase.com/blog/top-mysql-sql-review-tools/)
- [Top Postgres SQL Review Tools in 2026](https://www.bytebase.com/blog/top-postgres-sql-review-tools/)
- [SQL Review: From Linting to Governance](https://www.bytebase.com/blog/sql-review-tool-for-devs/)
- [Is SQL Review Necessary? Real Talk From Developers](https://www.bytebase.com/blog/is-sql-review-necessary/)
- [How to Integrate Automatic SQL Review into GitHub](https://www.bytebase.com/blog/integrate-sql-review-into-github/)