Data & Platform
Schema design, execution-plan-driven performance tuning, index strategy, and safe schema change on databases that cannot go down.
01The problem
Systems rarely fail because the screens were wrong. They fail because the model was never made explicit, the indexes were guessed at, a data type was chosen carelessly three years ago, or a migration broke a dependency nobody knew existed. By the time it surfaces it is a production incident during your busiest week.
02How we approach it
We read execution plans rather than guess at causes. Implicit conversions, table scans and lock contention get found at design time. Schema changes are dependency-mapped before they run — indexes, views, procedures and constraints identified, compatibility assessed, change planned, then validated against row counts and business totals.
03What you get
04How it runs
Capture the real workload. Slow is a symptom; the plan tells you the cause.
Before changing anything, know every index, view, procedure and constraint that touches it.
One structural change at a time, each one reversible.
Row counts, totals and business keys before and after. Numbers must agree or the change does not stand.
Overhauling legacy T-SQL and stored procedures through execution-plan analysis produced a 40% reporting performance improvement in a prior enterprise engagement.
05Where we have done this
Tell us what the system has to do and where it currently breaks. You will get a reply from the engineer who would do the work.