Database Design & Optimisation

Almost every system that has slowed to a crawl was fine at launch. The data model was built for the first thousand rows and never revisited, and the cost of that only becomes visible once there is enough data to hurt.

On a new build we model the data first, because the schema is the decision that is most expensive to change later. On an existing system we go the other way: find the queries that actually cost you, read the plans rather than guessing, and fix the cause, which is usually a missing index, a query pattern that scales with your row count, or a model that stores the same fact in three places.

Where the honest fix is a change to the model rather than another index, we say so, and we plan the migration so it can run without taking the system down.

What you get

• A schema modelled to how the business actually reads and writes, not just stores
• Slow queries identified from real execution plans rather than guesswork
• Indexing and query changes with the before and after timings to show for it
• Migrations planned to run without downtime, and reversible