Database Design, Optimisation and Management

It usually comes down to one of five things: queries running without a supporting index, too many unnecessary indexes slowing down every save, reports running on the same database as live users, records locking each other under load, or a table structure that forces heavy joins for ordinary operations. We identify which one it is by analysing your actual queries rather than guessing.

In most cases yes. Many improvements, particularly indexing and query changes, can be applied while the system stays live. Larger structural changes are rehearsed on a copy of your real data first so we know exactly how long they take, and we schedule those for a quiet window with a rollback ready.

Often a large part of the improvement comes from the database alone through indexing, configuration and query changes. Where the application itself is generating inefficient queries, we document precisely what needs changing so your developers can apply it, or we can make those changes ourselves as agreed scope.

By restoring one, which is the only real test. We restore a backup into a separate environment and confirm the data is complete and usable. A backup job that reports success has not proved anything until someone has recovered from it.

Yes. We handle migration between hosts, versions and cloud providers, usually with little or no downtime by keeping the new location in sync while the old one continues serving traffic, then switching over quickly. Record counts are reconciled before the old system is retired.

For business data with customers, orders and relationships between records, a relational database such as MySQL or PostgreSQL is almost always the better choice. Document databases suit cases where the structure genuinely varies from record to record. Most projects that chose otherwise did so for reasons that did not survive contact with real reporting requirements.

Yes. We identify duplicates, records pointing at things that no longer exist and values that break the rules, then correct them in a controlled way with a report of every change. We do not silently fix records, because a quiet correction hides the cause that will produce the same problem again.

Not always. A useful review can often be done from the structure, query logs and monitoring output alone. Where live access is genuinely needed, we ask for limited permissions for a defined period, under a confidentiality agreement signed before the work begins.

A review is a defined piece of work priced separately from any fixes, so you can get an independent picture before committing to anything larger. The findings come with the effort each fix requires, and you are free to have your own team implement them.

Yes. Monthly support covers monitoring, backup verification and restore testing, capacity planning, version upgrades, index maintenance and response when something goes wrong. Any database holding orders, payments or customer records should have someone accountable for it.