Top Oracle SQL Review Tools in 2026

Oracle SQL review has an odd shape. Most of the code worth reviewing isn't a migration script at all. It's PL/SQL: packages, triggers, procedures that have lived in the database for fifteen years. So the tooling splits in two. One group analyzes PL/SQL logic. The other checks the DDL and DML you are about to run against production. Few tools do both, and the best-known community tool for the first job was archived this year.

Every pick targets Oracle or PL/SQL specifically (or, for SQLFluff and Flyway, has a maintained Oracle dialect), works on its own, and was checked against release history in September 2026. The ones that fail that last check get their own section.

The layer you need decides the tool:

PL/SQL compile-time warnings (built in)#

Every Oracle database already has a PL/SQL linter, and most teams have never turned it on. Set PLSQL_WARNINGS and the compiler reports warnings in three categories (SEVERE, PERFORMANCE, INFORMATIONAL) alongside the usual compile errors, visible in USER_ERRORS or with SHOW ERRORS.

ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL', 'ERROR:06009';
ALTER PACKAGE billing_pkg COMPILE;

The second value is the useful trick. ERROR:06009 promotes one warning to a hard compile error, so a deploy script fails instead of printing a line nobody reads. PLW-06009 is the one to promote first: an OTHERS handler that doesn't end in RAISE, which is how errors get swallowed silently. Also worth knowing are PLW-07204 (a conversion away from the column's type, which can stop Oracle from using the index) and PLW-05018 (a unit with no AUTHID clause, so it quietly runs with definer rights).

The limit is where it runs. The compiler only sees code as it compiles into a live database, so a script sitting in a pull request gets nothing, and it has no opinion about table design or a DELETE without a WHERE.

Best for: every Oracle team. It costs one session setting.

SQLcl CODESCAN#

Oracle's own command-line tool has a linter that almost nobody mentions. SQLcl's CODESCAN checks files against the Trivadis PL/SQL & SQL Coding Guidelines, working on a directory rather than on compiled code:

sql /nolog
SQL> codescan -path ./src/plsql -format json -output codescan.json

Findings come back with guideline IDs like G-1010: Try to label your sub blocks. There's also set codescan on for interactive warnings in a session, off by default.

It's free and already installed if you use SQLcl. The configuration is thin, though: as of the 26.2 docs, the settings file supports an ignore list and not much else, so you can switch rules off but not tune them.

Best for: teams that want guideline checks in CI without adding a vendor.

dbLinter#

dbLinter is the successor in spirit to PL/SQL Cop, and it shares a maintainer: Philipp Salvisberg, who also wrote the PL/SQL & SQL Coding Guidelines. The standalone guidelines were archived in July 2026 with v4.4 as the final version, and the rules now live on inside dbLinter. A joint project between United Codes and Grisselbav, it has 180+ rules covering Oracle and PostgreSQL, including APEX-specific ones. Version 1.10.0 shipped in August 2026.

It runs as a VS Code extension (also on Open VSX, so Cursor and VSCodium work), a CLI, and a SonarQube plugin, with the rule set configured centrally so a team shares one config instead of passing files around.

Read the licensing carefully. dbLinter is proprietary. The anonymous tier only includes rules that need no configuration, and the free Starter tier (one seat) adds a configurable rule set. Quick fixes and the CLI for CI/CD start at Essential (€50 per seat per month), and the SonarQube plugin needs Professional (€80 per seat per month). United Codes quotes both from 5 seats.

Best for: PL/SQL-heavy teams that want the Trivadis guidelines as a maintained product, in the editor and in CI.

SonarQube (PL/SQL)#

If your organization already runs SonarQube for application code, PL/SQL can land on the same dashboard. SonarQube Cloud lists 186 PL/SQL rules (September 2026), with keys like plsql:DeleteOrUpdateWithoutWhereCheck and plsql:BadRaiseApplicationErrorUsageCheck, which checks that custom error codes sit in the -20000 to -20999 range.

Edition matters. On SonarQube Server, PL/SQL analysis starts at Developer Edition; the free Community Build doesn't include it. SonarQube Cloud includes it on the standard plans, free for private projects up to 50k lines of code and 5 members.

One gotcha from the docs: some rules only fire when SonarQube can read the data dictionary. Without sonar.plsql.jdbc.url and credentials, the analyzer can't look up column definitions, and you get fewer findings than the rule list suggests. Teams on Community Build can instead use ZPA, an LGPL-3.0 PL/SQL analyzer plugin.

Best for: organizations that want one quality gate for all their code and already pay for SonarQube.

SQLFluff (Oracle dialect)#

SQLFluff is a style linter. It enforces casing, spacing, and layout against an oracle dialect that, per its docs, includes PL/SQL. Version 4.3.0 (August 2026) fixed a batch of Oracle parsing gaps: SELECT INTO record fields, &1 substitution variables, FOR UPDATE ... SKIP LOCKED.

That list tells you where the rough edges are. SQL*Plus scripts mix client commands with SQL and PL/SQL, and that's where the parser still struggles: an open issue reports 4.3.0 misreading a bare / inside CREATE VIEW as the SQL*Plus run command. Expect some noqa comments on a legacy codebase. There is only one Oracle-specific rule (OR01), and it's about empty / batches, not PL/SQL logic. Fine for style, useless for finding bugs.

Best for: one consistent SQL style in CI, if your scripts aren't heavy on SQL*Plus commands.

Toad for Oracle Code Analysis#

Toad has shipped code analysis for years, and in many Oracle shops it's the reviewer already on every DBA's desktop. It checks code against rule sets (the default is "Top 20", from Steven Feuerstein and Bert Scalzo) and adds complexity metrics rolled up into a Toad Code Rating from 1 (best) to 4 (worst), with violations underlined in the editor. Per Quest's store, this comes with the Professional edition and up.

The Toad DevOps Toolkit exposes Code Analysis as scriptable objects for CI. That route works, but Toad is a desktop tool first, and it's heavier than running a CLI in a container.

Best for: teams already licensed for Toad Professional. Check that code analysis is actually switched on.

Flyway code review (Redgate)#

Flyway supports Oracle, and flyway check -code runs static analysis on your migration scripts before they deploy. The command is available in all editions; on Community it calls a SQLFluff install you manage yourself. Enterprise adds Redgate's own rules, aimed at data loss and security, such as RG06 (DELETE without WHERE) and RG09 (UPDATE without WHERE), plus regex rules you write yourself with an oracle dialect option, and the option to fail the pipeline on a violation. Redgate has been moving this packaging around, so confirm what your edition includes.

This is the pick closest to the Bytebase section below, so it's worth marking the line. The code check reads the migration file and reports on it. It doesn't ask the target database whether those columns exist, and it has no opinion about who approved the change or whether the SQL that ran was the SQL that got reviewed. Flyway reviews the script; a governance layer reviews the change.

Best for: teams that already deploy Oracle migrations with Flyway and want review in the same step.

utPLSQL#

utPLSQL is a testing framework, not a linter, and it's here for the same reason pgTAP is on the Postgres list. A linter tells you a statement looks risky. A test tells you the package still returns the right answer after the change. You write test packages with annotations like --%suite and --%test, and run them inside the database.

It's Apache-2.0 and active: v3.2.3 came out in July 2026, and the current line requires Oracle Database 19c or newer. Reporters for SonarQube, Jenkins, and TeamCity come with it, plus code coverage.

Best for: any team whose PL/SQL carries business logic worth protecting.

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

PL/SQL Cop (db* CODECOP) is archived. It's still named in 2026 "best PL/SQL analysis" lists, but all four repositories are archived, with a "no longer maintained" notice added in February 2026 and the last release in March 2024. The guidelines it enforced live on; dbLinter and SQLcl CODESCAN are where they went.

Oracle SQL Developer is not a linter. It's a good tool, but the current VS Code extension (26.2.1, August 2026) has no lint feature of its own. What it does have is an embedded SQLcl, so the CODESCAN command above works from there. When a list names SQL Developer as a "SQL review tool", the feature it remembers is most likely the CODECOP extension above.

Bytebase#

Bytebase sits on the other side of the split. It reviews the DDL and DML in a change before it runs, and attaches that review to an approval workflow. Oracle 11g and above is supported, from the same console that handles MySQL, Postgres, SQL Server, and 20+ other engines.

The SQL review rules cover the common DDL and DML risks, and several are Oracle-shaped rather than generic:

• WHERE is required on UPDATE and DELETE, and optionally on SELECT.
• A function or calculation on an indexed column in the WHERE clause is flagged, because it keeps Oracle from using that index.
• DML can be validated against the target database with EXPLAIN PLAN FOR, which asks Oracle to parse the statement and build a plan without running it. An invalid column reference fails review instead of failing at rollout.
• Identifier case can be enforced. Oracle uppercases unquoted identifiers, and a quoted lowercase name is a different object that someone will later fail to find.
• A prior-backup check saves the affected rows into a bbdataarchive schema, which is what makes one-click data rollback possible on Oracle.

Rule levels attach to an environment or a project, so the same rule can warn in dev and block in prod. None of these rules look inside PL/SQL program logic, though. Bytebase won't tell you an OTHERS handler swallows errors. dbLinter and the compiler will.

Best for: teams that need Oracle changes reviewed and approved before they run, with the same workflow across their other engines.

Comparison#

Read it by the layer you're missing, not by which row has the most rules.

Picking one#

Turn on PLSQL_WARNINGS today and promote PLW-06009 to an error. It's free, it's already there, and it catches the swallowed exception, the bug that turns a failed job into a job that silently did nothing.

Then pick one guideline linter. If you want zero new vendors, use SQLcl CODESCAN. If PL/SQL is a large part of what your team writes and you need deeper, configurable enforcement across the editor and CI, dbLinter is worth evaluating; start on the free tier. Choose SonarQube only if it's already your organization's quality gate; adopting it just for PL/SQL is a lot of platform for one language. Add utPLSQL once a package's correctness matters more than its style, which for most billing or ledger code is already true.

Bytebase is the layer to add when the question changes from "is this code good" to "who approved this change, and did it run the way it was reviewed." To try it, set up a SQL review policy and attach it to the environment your Oracle databases sit in.

For the framework behind this list, see SQL review: from linting to governance. On a mixed estate, the same comparison exists for SQL Server, Postgres, and MySQL.