“The review singled out three statements responsible for most of our I/O. Two index changes and one rewritten aggregate—nothing exotic. Wish we had booked the audit before the Black Friday load test, but the follow-up call helped us prioritize.”— S.K., retail platform (MySQL 8)
What clients report after we leave the plans on the table
Names are shortened where contracts require it. Each note ties to a specific engagement type we still offer.
“They pushed back politely when we asked for a blanket ‘add Redis’ recommendation. Instead they showed where our repository was opening overlapping transactions. Fixing that mattered more than another cache layer.”— D.M., fintech API (PostgreSQL)
“Documentation was dense but usable—exact statement hashes, before/after plans, and a rollback note for each DDL script. Our DBA signed off in one review meeting.”— A.P., municipal records modernization
“ORM mapping review found a lazy collection that exploded on our admin export. The fix was small; finding it without their trace would have taken us longer. Scheduling across time zones was slightly awkward—that is on us, not them.”— J.T., SaaS analytics (Hibernate)
Case story: warehouse allocation API
A Gauteng logistics client engaged GridConduit for a query performance review after p95 allocation latency crossed 800 ms during morning peaks. The team suspected hardware limits; metrics showed CPU headroom but rising buffer read waits.
We captured plans for the top twelve statements by total time, mapped them to C# repository methods, and found a parameter sniffing issue on a SKU lookup combined with a wide covering index that discouraged seeks. Recommendations included a filtered index, a plan guide for the worst offender, and narrowing a transaction that held locks across two round trips.
After deployment, the client reported p95 near 220 ms on the same window—no server resize. We held a 45-minute retrospective to set alert thresholds on lock duration rather than CPU alone.
Case story: membership renewal batch
A nonprofit’s nightly renewal job began exceeding its maintenance window when membership grew past 400k rows. The data-access audit traced ORM batching defaults that issued per-row updates instead of set-based SQL.
GridConduit drafted a staged migration: temporary table load, single merge statement, and application change to chunk by district code. The job finished under two hours on the next run; the client kept our checklist for future batch imports.