Database design and optimisation.
Schema design that holds up, and query tuning for databases that have slowed to a crawl.
Most applications that get slow are not slow because of the language they are written in. They are slow because of what they ask the database to do. A page that was fine with a thousand rows becomes unusable at a hundred thousand, usually because of a missing index, a query inside a loop, or a schema that made sense before the requirements changed.
What’s included
- Schema design and normalisation for new applications
- Query analysis and optimisation with execution plans
- Index strategy — adding what helps, removing what costs
- Fixing N+1 queries and query-in-loop patterns
- Safe migrations on live databases without downtime
- Archiving and partitioning strategy for large tables
- Backup, restore testing and integrity checks
Finding the actual bottleneck
The first step is measurement, not guesswork. Slow query logs, execution plans and real timings tell you where the time goes. Very often a single missing index on a foreign key accounts for most of the problem, and the fix takes minutes once you know where to look.
The N+1 problem
Loading a list, then running one more query per row to fetch related data, is the single most common performance bug in web applications. It is invisible in development with sample data and severe in production. Fixing it usually means eager loading or a join, and can turn hundreds of queries per page into two.
Migrations without downtime
Altering a large table can lock it long enough to take the site down. On anything sizeable, that means an online schema change strategy, a tested rollback path, and running the migration when it will do least harm — not at 2pm on a Tuesday.
Common questions
Which databases do you work with?
MySQL and MariaDB most often, plus PostgreSQL and SQLite. The diagnostic approach is the same across all of them.
Our site got slow as we grew. Can you diagnose it?
Yes, and that is usually the right first engagement: a focused audit that identifies the actual causes and what each fix would involve, before committing to a larger project.
Can you optimise without changing the application?
Often, yes. Indexing and query changes frequently deliver most of the improvement without touching application logic. Where the schema itself is the problem, I will explain the trade-off.
Will optimisation risk our data?
Changes are tested against a copy first, and anything structural has a rollback path and a verified backup before it runs.
Have a project in mind?
Tell me what you're building and roughly when you need it. I reply to every genuine enquiry within one working day.