SQL Server schema design, query tuning and indexing — built correctly the first time, or fixed when an existing database is buckling under real traffic. If your app is slow, the cause is almost always here: a few queries and some missing indexes, not the hardware. Remote, worldwide.
Two kinds of work: building a database that stays fast as it grows, and rescuing one that's already grinding. Here's what each covers.
Find the queries actually costing you — missing indexes, N+1 patterns, blocking and stale statistics — and fix them, cheapest change first.
Tables, relationships and constraints designed so the data stays correct and the queries stay simple as the app grows.
The right indexes for how the app actually queries — not one per column, and not none. Measured against real execution plans.
Procedures, functions and triggers written to be readable and fast — with set-based logic instead of row-by-row loops.
Schema changes and data migrations planned so they ship without taking the system offline or risking the data.
A structured review of a struggling database — indexes, queries, blocking and growth — with a prioritised fix list you can act on.
Whether it's a fresh design or a rescue, the work is measured, not guessed — every change justified by an execution plan or a metric.
A lot of "slow database" problems are really application problems — how the code queries the data. Because I build the backend too, I fix the real cause, not just the symptom.
What's slow, when, and for whom. We separate a database problem from an application one before touching anything.
Execution plans, wait stats and the actual expensive queries — the diagnosis comes from data, not hunches.
Indexes, query rewrites and schema changes, cheapest and safest first, each one validated against the plan.
Re-measure under realistic load and show the before / after numbers, so the improvement is provable, not claimed.
You get every script, the audit report and a short list of what to watch as the data keeps growing.
A write-up and related services that show how I approach data — where slowness really comes from, and the layers around it.
Missing indexes, N+1 queries, blocking and stale stats — where to look first, and the cheapest fix to the last resort.
The ASP.NET Core layer that sits on the database — often where a "slow database" problem actually starts.
An ageing app grinding to a halt is often database and code together — I take on the whole rescue.
Tell me what's happening — the app is crawling, or you're designing something new. You'll get an honest read on the cause and a clear quote, with no pressure.