For reference and from practice.
At the top is our reference collection: topics we maintain continuously and expand step by step. Below it, articles and case reports from projects, talks and the work on our tools. Factual, with evidence and with their limits.
Reference
Maintained rather than published and forgotten: every page shows its status, its maturity level and a change log.
SQL Server performance: find the cause
Six diagnostic paths when SQL Server is slow: plans and parameters, blocking and timeouts, load and waits. With read-only SQL queries and examples from our lab.
Open the guide →SQL Server versions
Current build and end of support for SQL Server 2005 through 2025, complete update lists per version, and a build checker for the output of @@VERSION.
Understanding the optimizer
Why the same query is sometimes fast and sometimes slow: real execution plans to try out, parameter sniffing in the plan cache, and a comparison of the remedies.
Read chapter 1 →Articles & case reports
More Cores, Faster Cores or a Better Query?
When more cores help, when only a faster core does, and when a better query is the answer. With lab evidence and the metrics that show a real CPU bottleneck.
Will an Upgrade Make Our Application Faster?
An upgrade changes three things: engine, compatibility level and new features. How to separate gain from risk for your own queries, with lab evidence.
SQL Server Backup and Restore: The Basics
Full, differential or log? Learn how SQL Server backups work, how to run a verified restore, and how to get started with Ola Hallengren.
SQL Server Backup and Restore: Planning for the Real Incident
Point-in-time restore, COPY_ONLY, log chains and retention: how to check SQL Server backups and Ola Hallengren’s solution in day-to-day operations.
Same Query, Different Speed: sp_BlitzPlanCompare in the lab
Brent Ozar’s sp_BlitzPlanCompare in our lab on SQL Server 2022 and 2025: what it finds, what the findings mean, and how a difference becomes a cause.
When the index grows without maintenance: Why a stable page density does not mean a quiet index
Why a stable page density does not mean a quiet index: two indexes with no maintenance at all, grown to 3.6 million rows, settled around 68% page density in our test, with around 225 split log records per 10,000 inserts still occurring. Plus how to compare the cost of waiting with the cost of intervening.
Tidy, but no room: REORGANIZE, REBUILD and the next inserts
Why REORGANIZE saves hardly any split log records in our insert test, while a REBUILD with reserve achieves much more: after REORGANIZE, 14,870 split log records for the next 100,000 inserts, after REBUILD with fill factor 81 only 2,632. Measured on SQL Server 2022 and 2025, with page distribution, cost by recovery model and a 60-day comparison.
Room for the next row: How an index reads, fills and splits pages
Nine page pictures instead of formulas: pages and signposts, page splits, fragmentation, page density, fill factor, REORGANIZE, REBUILD and statistics. And why a low fragmentation value alone does not make a good maintenance decision.
The reader that locks the table: SELECT, prefetch and lock escalation
Measured on SQL Server 2019, 2022 and 2025: why a SELECT under READ COMMITTED holds on to locks, when it escalates and which countermeasures work. With an X-ray view and a quiz.
Read the article →Where does the time go? Query Store with triggers, procedures and functions
Measured on SQL Server 2019: where duration overlaps, where work has no entry of its own, and why totals mislead. With a fast-motion view and a quiz.
Read the article →T-Lift: dynamic SQL without writing it by hand
Our T-SQL precompiler turns catch-all procedures into parameterized dynamic SQL with suitable plans. The source stays readable T-SQL.
Read the article →SQL Server Iceberg: how deep can you go?
The browser game: dive down along the iceberg, solve 15 real performance problems, one life. Cthulhu waits at the very bottom.
Dive in →
What evidence looks like
A look inside PSG QX: from the timeline through the expensive line of code to the finding with proof, unknowns and next step to verify.
Take a look →Local. Deterministic. Verifiable.
Why we rely on data mining for our analyses, long before generative AI, and what “deterministic” means for your findings.
Read more →The statistics were right. An old plan stood in the way.
A plan forced in Query Store kept the optimizer from using a new statistic. Found, fixed and measured again, without changing a single line of application code.
To the case →
Performance Driven Development
Considering performance in development and architecture from the start, instead of repairing it in operations.
To the training courses →
Always pushing ahead
From 1994 to today: CeBIT 2008 on the Microsoft stage, columnstore at the partner conference in 2012, In-Memory OLTP since 2015.
To the milestones →
Hamburg SQL Server user group
Organized by us since 2005, today the Microsoft Data Platform Community Hamburg.
To Meetup ↗