You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
sqlopt
committed
docs(readme): redesign with logo, badges, and brand-matched layout
Centered logo + tagline + status badges, a three-lens table, prescriptive/
private sections, the quality bar (135 scenarios · F1 1.000), quick start,
architecture, and the one-brand-every-engine roadmap. Links to dbopt.org and
the docs/. Same verified facts, far cleaner presentation.
> **Free and open.** No per-seat cost, no paywalled features. The goal is to give
19
-
> SQL developers and DBAs what the commercial tools do — without monetizing their pain.
27
+
---
20
28
21
-
## Documentation
29
+
**dbopt** reads your T-SQL, your execution plans, and your live server metrics — then tells you exactly
30
+
what's going to hurt and **how to fix it, with the reasoning cited**. It analyzes statically and from the
31
+
*estimated* plan, so there's **no execution, no locks, no load on production**. Nothing leaves your machine
32
+
unless you explicitly choose a cloud model.
22
33
23
-
-**[Who is dbopt for?](docs/WHO-IS-DBOPT-FOR.md)** — what it does for SQL developers, DBAs, and platform teams (start here).
24
-
-**[Access & Permissions](docs/ACCESS.md)** — exactly what database access each capability needs, with a least-privilege grant script and a per-platform matrix (self-managed / RDS / Azure).
25
-
-**[Roadmap to "complete"](docs/ROADMAP-TO-COMPLETE.md)** — honest gap analysis vs the commercial field and the prioritized plan to close it.
34
+
> **SQL Server is the product today** — comprehensive and fully tested. PostgreSQL and MySQL are on the
35
+
> roadmap; the engine seam is already in place so they slot in without disturbing the SQL Server core.
36
+
>
37
+
> **Free and open.** No per-seat cost, no paywalled features — what the commercial tools do, without
38
+
> monetizing your pain.
26
39
27
40
---
28
41
29
-
## Why this exists
42
+
## Why it exists
30
43
31
-
Slow SQL is the silent tax on every data-heavy company: the query "that's been
32
-
running since last night," the 2 a.m. incident, the cloud bill that keeps
33
-
climbing. The usual ways to fight it are unsatisfying:
44
+
Slow SQL is the silent tax on every data-heavy company: the query "that's been running since last night,"
45
+
the 2 a.m. incident, the cloud bill that keeps climbing. The usual fixes disappoint —
34
46
35
47
-**Expensive, SQL-Server-locked enterprise suites** that cost more than the problem.
36
48
-**Tools that only react _after_ a query runs** — by then the damage is done.
37
-
-**Raw DMV dumps** that tell you _what_ is slow but not _why_ or _what to do_.
38
-
-**Cloud SaaS** that wants you to ship your queries and schema off-box — a
39
-
non-starter for pharma, finance, and healthcare.
49
+
-**Raw DMV dumps** that tell you *what* is slow but not *why* or *what to do*.
50
+
-**Cloud SaaS** that wants your queries and schema off-box — a non-starter for pharma, finance, healthcare.
40
51
41
52
dbopt takes the opposite stance on all four.
42
53
43
-
## What dbopt gives you
44
-
45
-
-**Shift-left analysis.** Catch the anti-pattern _before_ the query runs.
46
-
dbopt analyzes statically and from the *estimated* plan — **no execution, no
47
-
locks, no load on production.** It will happily dissect a query you'd never
48
-
dare run. (We've pointed it at 100M+ row tables and optimized a multi-hour
49
-
query without executing it once.)
50
-
-**Prescriptive + cited fixes.** Not just "here's a finding" — the concrete
51
-
rewrite *and* the engine-level reasoning behind it. 59 rules, each with a
52
-
recommendation.
53
-
-**Three lenses, one tool.** Static T-SQL analysis · execution-plan cost
54
-
breakdown · live DMV + continuous monitoring. Most tools do one.
55
-
-**Local-first and private.** A single Rust binary. SQLite for storage. An
56
-
optional **local** LLM (Ollama) for AI help. Your SQL and schema never leave
57
-
the box unless you explicitly pick a cloud model.
58
-
-**Continuous sentinel.** A lightweight daemon polls your instance, builds a
59
-
time-series, and surfaces a weekly **pain report** — top waits, regressions,
60
-
unused indexes — so you catch trouble early instead of at 2 a.m.
61
-
-**Grounded AI assistant.** The assistant gets your SQL *and* the static
62
-
findings injected as context, so it explains and rewrites with real grounding
63
-
— and you can fan the same prompt out to several models to compare.
64
-
65
-
## Who it's for
66
-
67
-
DBAs and senior backend/data engineers — especially teams **without** a
68
-
dedicated performance expert, and regulated shops that **can't** send data to a
69
-
cloud service.
54
+
## What you get
70
55
71
-
---
56
+
### 🔭 Three lenses, one tool
57
+
58
+
|| Lens | What it does |
59
+
|---|------|--------------|
60
+
|**01**|**Static**| A token-level T-SQL analyzer — **59 rules** across hygiene, sargability, deprecated syntax, modern rewrites, plan-shape, locking, tempdb, statistics and index design. Runs in-browser via WebAssembly or as a CLI. **No connection required.**|
61
+
|**02**|**Plan**| Fetches the *estimated* plan (`SET SHOWPLAN_XML`, compile-only — never runs the query) and breaks down operator cost, scans vs. seeks, and spill risk. |
62
+
|**03**|**Live**| Pulls DMVs (index usage, missing indexes, sizes) on demand, and the **sentinel** daemon polls Query Store, waits, deadlocks and index usage into a local SQLite time-series → a weekly **pain report**. |
72
63
73
-
##How it works
64
+
### 🛠 Prescriptive & cited fixes
74
65
75
-
dbopt looks at your workload through three complementary lenses:
66
+
Not just "here's a finding" — the concrete **rewrite***and* the engine-level **reasoning** behind it.
67
+
Every rule ships a recommendation, and the grounded **AI assistant** gets your SQL *and* the findings as
68
+
context (fan one prompt out to several models to compare). Everything is **version-aware (2014 → 2025)** —
69
+
a 2022+ rewrite is never suggested against a 2014 target.
76
70
77
-
1.**Static analysis** — a token-level T-SQL analyzer (59 rules across hygiene,
78
-
sargability, deprecated syntax, modern rewrites, plan-shape, locking, tempdb,
79
-
statistics, and index design). Runs in-browser via WebAssembly or as a native
80
-
CLI. No connection required.
81
-
2.**Execution-plan analysis** — fetches the *estimated* plan (`SET SHOWPLAN_XML`,
82
-
compile-only) and breaks down operator cost, scans vs. seeks, and spill risk.
0 commit comments