Performance work should resolve disagreement, not create more of it.
Slow systems often attract conflicting explanations: storage says the database is the problem, developers blame infrastructure, and the database team sees expensive code. The objective is not to win that argument. It is to connect waits, workload, execution plans, resource use, and application behavior into one evidence-backed explanation.
What the engagement examines
Workload baseline
Latency, throughput, resource pressure, workload shape, and the business-visible symptom.
Query behavior
Query Store, plan regressions, parameter sensitivity, compilation, and expensive statements.
Concurrency
Blocking chains, deadlocks, isolation behavior, long transactions, and application patterns.
Index and data design
Access paths, missing or overlapping indexes, statistics, cardinality, and data growth.
Instance configuration
Memory, MAXDOP, cost threshold, tempdb, file layout, autogrowth, and relevant settings.
Capacity and architecture
CPU, memory, storage, virtualization, replicas, licensing tradeoffs, and scale limits.
Deliverables
- A plain-English explanation of the dominant constraints and their confidence level.
- A ranked remediation list separating low-risk quick wins from changes requiring testing.
- Query, index, configuration, or architecture recommendations with expected measurement.
- A validation and rollback plan for production-impacting changes.
- Optional paired implementation and knowledge transfer.
When another engagement is better
If the concern is broader than performance—restore confidence, security, maintenance, operational ownership, or version risk—the SQL Server Risk & Recovery Review is the stronger starting point.