Database development and optimisation

Applications get rewritten every so often, but the data carries on. A clumsy schema decision can haunt a business for a decade, slowing every report and complicating every feature. Good design uses real constraints such as foreign keys, unique rules and sensible types, so that the database itself refuses bad data instead of relying on every piece of code to remember the rules.

Many businesses come to us with a database that has grown informally: an Access file on a shared drive, or a spreadsheet that has quietly become the system of record. These work surprisingly well until they don’t. Moving off them doesn’t have to be dramatic, and we can often keep a familiar interface while moving the data underneath to something sturdier.

When a database is slow

When a system gets slow, people often assume they need bigger servers. Usually the problem is a small number of unindexed or badly written queries, and fixing those is much cheaper. We look at slow query logs and execution plans first. Only after that would we consider caching, read replicas or partitioning, each of which brings its own complexity.