Top SQL Server SQL Review Tools in 2026

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 +!:

<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 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 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 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 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 — 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 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, 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 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 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 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#

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 is the place to start. The same comparison exists for MySQL and Postgres if you run a mixed estate.