dbopt reads your queries, your execution plans and your live server metrics, then tells you what is going to hurt and how to fix it — with the reasoning cited. Reading a query or a saved plan runs nothing at all; the live surfaces read only metadata and telemetry.
The real Rust engine, compiled to WebAssembly and served from this domain. Once it loads, analyzing costs no network at all. your SQL uploaded: 0 bytes
A query that was fine for two years meets a table that finally got big. Nothing changed in the code. The plan changed. By the time a dashboard turns red, the damage is already measured in timeouts and a cloud bill.
The usual answers disappoint. Enterprise suites cost more than the problem. Raw metric dumps tell you what is slow, never why or what to type next. Hosted services want your schema and your queries off-site — a non-starter in pharma, finance and healthcare. And nearly all of them only speak up after the query has already run.
dbopt reads the query itself. A token-level analyzer catches the same problem in review, on a laptop, with no server involved — and hands you the rewrite along with the reason the optimizer cared.
Most tools watch one angle. dbopt fuses three into a single verdict you can act on.
104 rules across sargability, index design, plan shape, hygiene, modern rewrites, locking, tempdb, transactions, security and datatypes. Runs in your browser or as a CLI, with no connection at all.
Fetches the estimated plan — compile-only, the query never runs — and breaks down operator
cost, scans versus seeks, spill and lookup risk. A saved .sqlplan reads the same
way with no server at all: dbopt lint plan.sqlplan.
Real-time vitals on demand, plus a poller that samples query history, deadlocks and index usage into a local time-series, with thresholds and webhook alerts.
Every rule ships the concrete rewrite, not just a warning.
A findings list ordered by severity alone tells you a heap is a heap — not whether it holds
900 rows or 262 million. Findings that name a real object are ranked by that object's
measured rows and reserved space, read from sys.dm_db_partition_stats and shown
beside the finding. Size orders findings within a severity; it never promotes a tuning
opportunity above something that is actually breaking.
Usage-based advice is only as old as the DMV counters behind it, and SQL Server resets those on every restart. Each index recommendation now shows the reads and writes actually recorded, says no usage recorded since restart when there are none, and drops to “estimated” rather than pretending a zero was measured. The health headline is the worst of all three lanes, so a database that has never been backed up cannot grade as excellent because its queries are fast.
Each finding explains what the optimizer does and how the rewrite changes the plan, so you can argue it in review rather than take it on faith.
Advice is gated to your target engine. A 2022+ rewrite is never suggested against a 2019 server — try it in the demo above.
The assistant receives your SQL and its findings as context. Run a local model and nothing leaves; pick a cloud model and only that prompt does.
Three tools, three different jobs.
| Free DBA scripts | Commercial monitors | dbopt | |
|---|---|---|---|
| Cost | Free | Per-instance licence | Free & open |
| Works with no connection | No | No | Yes — SQL + saved plan file |
| Catches it before it runs | No | No | Yes |
| Tells you what to type | Some advice | Metrics, rarely fixes | Rewrite + reason |
| Your data leaves the box | Never | Often a hosted service | Never, unless you pick a cloud model |
| Runs in CI | No | No | SARIF, exit codes |
| Cross-platform GUI | Vendor-tool bound | Windows-centric | Linux, macOS, Windows |
dbopt is the only one of the three that can tell you a query is wrong before it has ever run — and the only one that does it without your queries leaving the building.
Every query dbopt runs hits catalog views, dynamic management views or query history — metadata, never table data.
Estimated plans are compile-only. DDL is preview-only — Safe-Apply never runs a change for you. The one path that does execute — capturing an actual plan — runs inside a transaction that is always rolled back, and tells you what the batch is estimated to cost before it starts, so a heavy query on a busy server is your decision rather than a surprise.
Linux, macOS, Windows. SQLite for storage, the web UI embedded inside. Nothing else to install.
A prompt you hand to a cloud AI model, and an anonymous version check you can switch off. That is the complete list for the installed app: its fonts and scripts are compiled into the binary, so with the update check off it makes no network request of its own. This marketing site counts visitors like any other; the app does not, and never talks to us.
measuring…
Those numbers are measured in your browser as you use the analyzer above — not copied from a promise we wrote. Open your network panel, hit Analyze, and watch nothing happen.
A tagged scenario corpus checks that covered rules fire when they should — and stay silent when they shouldn't.
What these numbers do and don't prove. The eval corpus is hand-authored, so its F1 is
self-graded: it proves no regression on the cases we wrote. Every one of the 104 rule ids
has a scenario, plus 13 more covering the 12 plan-XML and DMV checks. Two further measures run
against 71,758 lines of third-party production T-SQL we did not write — DBA tooling and
application schemas, which fail differently. For false positives, every error-and-above finding
is hand-classified: 143 high-severity findings. For false negatives — which no corpus of
real code can measure, since you cannot count what a linter failed to say — defects whose rule
is known by construction are planted into that same code behind hostile preceding context:
4,050 injected, recall 1.000. A second corpus — 6.6 MB of expert T-SQL (First Responder Kit, Ola Hallengren, sp_WhoIsActive, tSQLt, DarlingData, Microsoft samples) — had every rule that fired hand-triaged at every severity: false-positive rate 42 % before the 0.4.4 fix wave, 5.4 % after. And a blind trial (tools/blind-trial/: 18 planted defects, 5 look-alikes, independent builder and grader) went from 11 hits and 5 false alarms to 18 / 18 with none. Treat all of these as our own classification of our own tool: an
independent review disputed 17 of an earlier run's 161 findings, all since fixed. Reproduce with
cargo run -p eval -- --html, tools/heldout-corpus.sh and
tools/seeded-defects.py.
Engine-agnostic from the core out: every rule declares which database it applies to, so a new engine plugs in behind the same API, UI and report without disturbing the ones already shipping. Ask for an engine whose rules haven't landed and you get an empty report, never a guess.
# Linux & macOS curl -fsSL https://dbopt.org/install.sh | sh # Windows (PowerShell) irm https://dbopt.org/install.ps1 | iex # what you get dbopt lint ./db # the linter — offline, no connection dbopt-backend # the app — then open :3690 # developers cargo install dbopt # just the CLI + linter npm i dbopt-core # the analyzer in Node or the browser
Builds are not code-signed yet. Windows: More info → Run anyway. macOS: right-click → Open. Details · All releases and checksums