01
When a performance review is useful
A report that takes minutes, an endpoint that times out, or a query that degrades as records grow is a concrete starting point. The investigation follows the actual workload rather than assuming that more infrastructure is the answer.
- Review representative slow queries and execution plans.
- Examine join patterns, filters, scans, and index usage.
- Check the application path and data-transfer overhead.
- Compare changes under documented, representative conditions.
02
What the work produces
We define the affected queries and acceptance criteria first. The deliverable can include query or indexing changes, the measurements used to compare them, rollout considerations, and documentation for the team operating the database.
Performance changes need validation against realistic data and application behavior. A result from one workload is not a guaranteed speedup for another.
03
Relevant work: a 200M+ record system
My portfolio reports work on an anonymized US life-sciences lab-informatics platform: reducing a cross-module query from 15 minutes to 6 seconds, with 92% lower CPU load. The case study separates these reported outcomes from what can be publicly inspected.
Read the SQL performance case study ↗BEFORE WE START
Common questions.
Can you optimize PostgreSQL and MySQL queries?+
Both are part of my database work. The first step is reviewing the engine, schema, query plans, and workload so the engagement targets a specific bottleneck.
Will you need production data?+
We agree on the least information and access required. Sanitized schemas, execution plans, and representative test data may be sufficient for an initial review. Production access is not assumed.
Will my query become as fast as your case study?+
That cannot be promised. The outcome depends on the query, data distribution, schema, indexes, infrastructure, and workload. We establish a baseline and measure the actual result.