The layer everything else depends on, done right.
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.
Design it right, or make the slow one fast.
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.
Performance tuning
Find the queries actually costing you — missing indexes, N+1 patterns, blocking and stale statistics — and fix them, cheapest change first.
Schema & data modelling
Tables, relationships and constraints designed so the data stays correct and the queries stay simple as the app grows.
Indexing strategy
The right indexes for how the app actually queries — not one per column, and not none. Measured against real execution plans.
Stored procedures & T-SQL
Procedures, functions and triggers written to be readable and fast — with set-based logic instead of row-by-row loops.
Migrations, zero-downtime
Schema changes and data migrations planned so they ship without taking the system offline or risking the data.
Database health audits
A structured review of a struggling database — indexes, queries, blocking and growth — with a prioritised fix list you can act on.
What a database engagement includes
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.
- Schema & relationship design (or review)
- Query tuning against real execution plans
- Indexing strategy & cleanup of unused indexes
- Stored procedures, functions & triggers
- Zero-downtime migration planning
- Reporting & analytics queries
- A prioritised health-audit report
- Before / after numbers, so the win is provable
Someone who lives in the whole stack
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.
- I see the app and the database as one system
- N+1 and ORM traps caught at the source
- Fixes ranked cheapest-and-safest first
- No "buy a bigger server" as the first answer
- Clear before / after so you know it worked
- You keep every script and the full report
From "it's slow" to "it's fixed", in five steps.
Understand
What's slow, when, and for whom. We separate a database problem from an application one before touching anything.
Measure
Execution plans, wait stats and the actual expensive queries — the diagnosis comes from data, not hunches.
Fix
Indexes, query rewrites and schema changes, cheapest and safest first, each one validated against the plan.
Verify
Re-measure under realistic load and show the before / after numbers, so the improvement is provable, not claimed.
Hand over
You get every script, the audit report and a short list of what to watch as the data keeps growing.
The thinking behind the work.
A write-up and related services that show how I approach data — where slowness really comes from, and the layers around it.
Why your SQL Server is slow
Missing indexes, N+1 queries, blocking and stale stats — where to look first, and the cheapest fix to the last resort.
Backend & API development
The ASP.NET Core layer that sits on the database — often where a "slow database" problem actually starts.
Legacy .NET modernization
An ageing app grinding to a halt is often database and code together — I take on the whole rescue.
Power BI & reporting
Once the data is clean and fast, the next question is usually reporting on it. I build that layer too.
Questions about database work
Can you speed up a database without changing the application?
How do you find what is actually slow?
Will I need downtime for index changes?
Would it be cheaper to just buy a bigger server?
Database slow, or starting fresh?
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.