Microsoft's November 9, 2026 announcement adds version-store read metrics in Azure SQL Database across STATISTICS IO, execution-plan XML, extended events, and dynamic management views. The update helps investigate row-version traversal when queries become more expensive even though their plans appear unchanged. Microsoft announcement.
For a database team, this adds another line of evidence to a performance investigation. My proposed review would correlate version reads with the same workload window, query identity, CPU observations, and transaction activity already under investigation.
Understand What the Counter Measures
Microsoft Learn defines version reads as the number of earlier row versions traversed. Reading a row's current version adds nothing; traversing three older versions adds three. The metrics distinguish tempdb versions and in-row, off-row, and online-index persistent version-store reads. Counter semantics.
I would put the counter's unit and collection scope beside every chart or exported result. This gives the next reviewer enough context to interpret a change without assuming the number represents bytes or physical storage operations.
Keep the observation interval and workload conditions visible. A comparison becomes easier to assess when both samples describe the same question and the same unit of work.
Match the Evidence to Its Scope
The guide distinguishes running-request counters from completed-session counters and cached query statistics. It also notes that request and session counters can include compilation-related version reads, while execution-statistics DMVs cover execution. Metric locations and differences.
My proposed evidence sheet would name the source, capture time, query or session reference, and relevant execution count. Compare like-for-like observations before interpreting differences between two collection surfaces.
For a representative slow operation, retain the actual-plan evidence and its corresponding application timing. Ask the database owner to explain which portion of the request each result describes.
Investigate Cleanup and Transaction Behavior
Microsoft's announcement describes delayed cleanup and longer version chains as a cause of increased CPU and logical reads. Its ADR troubleshooting guide identifies long-running transactions and snapshot scans among the conditions that can hold cleanup back. ADR investigation guidance.
I would use the additional counters to form a testable hypothesis, then review transaction ownership and timing with the application team. Keep an unanswered causal question open until the relevant observations support it.
Imagine an application operation that remains open longer than its business owner expects. The investigation should connect that operation to the transaction evidence and determine why it did not finish promptly.
Agree on any corrective action through the service's normal change process. Preserve the original observations so the team can evaluate whether the approved change addressed the suspected behavior.
Check the Availability Boundary
At announcement time, Microsoft describes Azure SQL Database availability, with Managed Instance support planned for the always-up-to-date policy. Query Store integration is under consideration, and SSMS graphical-plan display of the new metrics is still forthcoming. Availability and tooling notes.
I would record the actual engine and client-tool environment used in the investigation. Verify the relevant fields on that environment before incorporating them into a shared runbook.
Give an unavailable metric its own disposition. A collection gap should lead to a specific next step rather than being interpreted as evidence that the workload performed no version traversal.
Compare the Outcome After a Reviewed Change
My acceptance comparison would repeat the agreed workload under comparable conditions and retain its duration, CPU evidence, version-read observations, and application result. Include enough context to identify other changes in the environment.
Review whether the intended business operation still produces the expected result. A performance improvement should remain connected to the service outcome that prompted the investigation.
End with a short explanation of what the evidence established, which hypothesis remains uncertain, and who owns the next action. Keep the data and reasoning together for the next incident review.
Practical Cloud Engineer Takeaway
Record the unit and scope of version-read counters.
Compare request, session, and cached-query evidence carefully.
Investigate cleanup delays with the transaction owner.
Verify engine and tooling availability explicitly.
Recheck application behavior after an approved correction.
Who Should Care?
Azure SQL administrators, application performance engineers, and operations teams investigating rising query CPU without an obvious plan change.
Bottom Line
The new metrics expose work that was harder to see during version traversal. Their value comes from a scoped investigation that connects counters, transaction behavior, and the application's observed performance.
No database query, transaction, session termination, configuration change, or performance test was executed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments