A tuning report is only as good as the evidence behind it. If the AI can’t see the execution plan, it has to guess which indexes will help. If it reads a stored procedure with the line breaks stripped out, the rewrite it gives you isn’t quite your code. And if it’s told an index has never been read, it needs to know whether the server restarted yesterday.
Release 3.0.5 is about that evidence. Since 2.2 we’ve changed how AI SQL Tuner Studio talks to the AI, cut the model list to the two that did best in our benchmarks, and opened all editions, including the Free edition, to every SQL Server. We also went through every tuning goal, one by one, to make sure each report is built on complete, correctly labelled data. Here’s what changed.
See it in action: Sample reports
A new service behind every analysis
Starting with 3.0, Studio sends each analysis through the AI SQL Tuner service, which handles licensing, quotas and model access. You don’t need your own Azure OpenAI deployment to get started. If you’d rather use your own endpoint, Pro, Team and Enterprise can still bring one.
A few things got noticeably better along the way:
- The Free edition works on any SQL Server. Free used to be limited to SQL Server Developer Edition, because there was no way to cap how much it was used. The service now enforces a monthly quota for every edition, so Free works with all versions of SQL Server, Azure SQL Database, Azure SQL Managed Instance and Fabric SQL Database.
- Reports appear as they’re written. Text starts streaming into the report pane about a second after the run starts. Before, the window sat empty until the whole report was ready, which could take two minutes on a large instance.
- Run Analysis responds right away. The license check now runs while you review the run plan, so there’s no dead pause after you click.
- Your analyses aren’t kept by default. Each run is answered and discarded. If you want your runs used to improve the advice, you can opt in under Privacy, and you can delete anything stored from inside the app.
- You still see everything before it’s sent. The run plan lists every collector and every DMV it queries before anything leaves your machine. Table data and query results are never sent.
Two models, chosen by benchmark
The model list is now short on purpose. GPT-5.6 Luna is available in every edition, and GPT-6 Sol is added for Team and Enterprise. We picked them by running real Index Tuning, Query Tuner and Code Review workloads against every candidate and measuring what the recommendations actually did to the workload. Models that fell short were withdrawn. One of them sometimes rewrote SELECT * into a column list that changed the query’s results, which is exactly the kind of advice you don’t want.
You can read the methodology and results on our benchmark page.
Reasoning effort: start with Medium
Reasoning effort sets how much the model reasons before it writes the report. We measured each level on our benchmark workloads, and the results changed our default:
- Medium is now the default.
- Low loses most of the benefit on Code Review, and with GPT-6 Sol some of its Code Review rewrites returned wrong results.
- High takes two to three times as long as Medium. Use it when a Medium report misses a root cause you can see in the data.
If you had Low saved, Studio moves you to Medium once when you upgrade. Pick Low again afterwards and it stays.
Query Tuner sees the execution plan
We found and fixed a bug that hit Query Tuner users who connect with a SQL Server login. The estimated plan was fetched on a second connection that was missing the password, so the login failed and the AI got only your query text: no plan and no table metadata. Windows and Microsoft Entra ID logins weren’t affected.
With the plan back in the input, results on our Query Tuner benchmark query improved sharply. Total workload time fell by 93 to 100 percent across all 15 benchmark runs, with no incorrect results.
Plan costs are also labelled correctly now. Each operator shows its own cost and its share of the statement, instead of the cost of everything beneath it. That’s why the root operator used to look like the most expensive one.
Fix Deadlocks rewrites the code involved
Fix Deadlocks used to send only the deadlock graph, so the AI could name the statements involved but had nothing to rewrite. Now Studio collects the code each process was running:
- the current definition of each stored procedure, function and trigger
- the text of each ad hoc batch, from the plan cache or the deadlock graph
The report cites the statements that take the conflicting locks, by line number. For each module whose full text was retrieved, it gives a complete CREATE OR ALTER definition. A module that shows up in several deadlocks gets one revised definition that fixes all of them.
Deadlock detection itself improved too. On Azure SQL Managed Instance, Studio now reads the system_health event files as well as the ring buffer. The ring buffer keeps only a short window, so a deadlock that had just happened could be missed. Deadlocks are also read correctly on SQL Server 2016.
Code Review and Locking and Blocking read the code as written
Code Review used to remove every line break and cut each definition at 4,000 characters. Without line breaks, a single -- comment looked like it commented out the rest of the module. Definitions now arrive whole, with line numbers, up to 40,000 characters each. Each one is labelled complete or truncated, so the AI gives a full replacement script only when it has seen the full definition.
Locking and Blocking used to send the first 2,000 characters of plan and deadlock XML, which rarely got past the header. Instead, it now sends a summary:
- For the blocking statement’s plan: every table and index it touches, with the operator, estimated and actual rows, its own cost, and whether it seeks or what forces a scan.
- For each deadlock: the processes involved, and which session holds or wants which lock on which table and index.
Advice about deadlock capture now matches what Studio actually found. “No deadlocks recorded”, “capture isn’t running” and “permission denied” each get their own guidance.
Index Tuning: sizes, drop candidates and uptime
- Every index recommendation states its size. This applies across Code Review, Index Tuning, Server Health, Query Tuner and Locking and Blocking. New indexes are estimated from row counts and column widths. Drops and rebuilds use the actual size on disk. The executive summary shows the net storage change of applying the whole report.
- Unused indexes stay in the analysis. On databases with many indexes, the ones that are maintained but never read used to be the first cut from the usage list. Half the list is now reserved for them.
- Each index says what it enforces, so an index backing a primary key or unique constraint doesn’t get recommended for a drop.
- Uptime is taken into account. Index usage statistics reset when SQL Server restarts. If the server has been up for less than a week, an unused index is listed as a candidate to confirm later, not dropped.
- No more
FILLFACTOR = 0. Indexes created without a fill factor were reported as 0, and the AI copied that into scripts SQL Server rejects. Studio now reports the fill factor that actually applies. - Query Store figures are accurate. Durations and CPU times were off by a factor of 1,000, and some execution counts showed the wrong columns. Both are fixed, and scoping Index Tuning to one table no longer times out on large databases.
Every figure has a source
Two changes apply to every goal:
- Every report sees the server’s start time and uptime, so the AI knows how much history the DMVs actually cover.
- Every figure in a report is either quoted from the collected data or labelled as an estimate, with what the estimate is based on. When the data a recommendation needs is missing, the report says so instead of filling the gap.
Editions, quotas and models
Every edition now supports all versions of SQL Server, Azure SQL Database, Azure SQL Managed Instance and Fabric SQL Database. The editions differ in monthly quota, models, reasoning levels, and whether you can bring your own AI endpoint:
| Edition | Analyses per month | Models | Reasoning effort | Bring your own AI endpoint |
|---|---|---|---|---|
| Free | 10 | GPT-5.6 Luna | Low, Medium | No |
| Pro | 50 | GPT-5.6 Luna | Low, Medium, High | Yes |
| Team | 150 | GPT-5.6 Luna, GPT-6 Sol | Low, Medium, High | Yes |
| Enterprise | 400 | GPT-5.6 Luna, GPT-6 Sol | Low, Medium, High | Yes |
Each analysis uses one unit of your monthly quota. The quota resets each month on the day your subscription started. The sidebar shows how many you’ve used and when the count resets. If a run times out, it doesn’t count.
Security and housekeeping
- The service endpoint ships with the app and can’t be changed in settings.
- The access token is encrypted at rest under your Windows account.
- Studio now requires Windows App Runtime 1.8, and the installer script upgrades an older runtime for you.
Conclusion
This release is about making sure the AI works from the right evidence. Query Tuner sees the plan. Fix Deadlocks sees the code. Code Review and Locking and Blocking see it as written. Index Tuning knows how long the server has been up. The models were picked by measured results, and all editions, including Free, now work with every version of SQL Server, Azure SQL Database, Azure SQL Managed Instance and Fabric SQL Database.
To start using AI SQL Tuner Studio 3.0.5, pick the edition that’s right for you or click Check for Updates inside Studio. To see the output before you install, look at the sample reports.
Leave a Reply