Capability
Data & Databases
Work on data-heavy applications: schema design, query optimisation, migration between systems, and moving reporting off the spreadsheet nobody owns.
What is actually included
- Schema design and normalisation for applications that will grow
- Query optimisation and indexing on large, slow tables
- Data migration and import pipelines between systems
- Reporting layers that replace a spreadsheet nobody owns
Most application problems are database problems
A great deal of my engineering career has been on data-heavy applications, where the interesting problems were never in the interface. Pages are slow because a query is doing a full table scan. Reports disagree because two systems define a customer differently. Something breaks at scale because the schema assumed a relationship was one-to-one and it stopped being one three years ago.
Query and schema work
Optimisation starts with measurement, not intuition. An execution plan usually tells you within minutes whether the problem is a missing index, a query that cannot use the index it has, or a data model that is forcing the join in the first place. The third case is the one people avoid, and it is often the only real fix.
- Schema design and normalisation for applications expected to grow
- Index and query optimisation driven by execution plans and real data volumes
- Migration between systems, including the reconciliation that proves it worked
- Reporting layers that replace the spreadsheet nobody owns
Migrations are mostly proof
Moving data between systems is rarely the hard part. Demonstrating that nothing was lost, transformed incorrectly, or silently truncated is the hard part, and it is what a migration should be judged on. That means row counts, checksums, and a reconciliation somebody outside the project can follow.