Database Optimisation & Maintenance

Three layers. Query optimisation — analysing slow queries with EXPLAIN, refining index strategy, and rewriting queries where it pays off. Schema optimisation — fixing modelling decisions that compound at scale, like missing constraints, denormalisation that has gone too far, or table structures that no longer match access patterns. Operational optimisation — tuning connection pools, vacuum and statistics maintenance, replication configuration, and IOPS allocation. Most projects involve some of each.

Yes — that's the standard expectation. Index additions can usually be done concurrently in PostgreSQL or with online DDL in MySQL. Schema changes use online-migration tooling (pg_repack, pt-online-schema-change, or equivalent) so tables are not locked during refactoring. Where a change cannot be done safely online — rare, but it happens — we plan a maintenance window with you in advance rather than discovering it during the change.

PostgreSQL is our deepest specialism — it powers most of the production systems we work on. MySQL where the existing stack requires it. MongoDB for document-oriented workloads. Redis for caching and session stores. Managed cloud databases on RDS, Aurora, Cloud SQL, Azure SQL, Cosmos DB, Firestore, and Supabase. We work on self-hosted and cloud-managed deployments equally.

Against a documented baseline. The audit phase captures current state — slow query log entries, P95/P99 latency per endpoint, IOPS, connection pool utilisation, replication lag. After optimisation we measure the same metrics and produce a before/after report showing exactly what changed. Improvements are quantified, not asserted.

Verified. Backup configuration failing silently is one of the most common database issues we find — typically nobody discovers the backups have not run for months until a recovery is genuinely needed. We test restoration of recent backups into a staging environment as part of the audit, and configure ongoing backup verification so failures are alerted rather than assumed away.

Yes. Alerts are designed with severity tiers and explicit routing. Critical alerts (production write failures, replication lag spike, connection pool exhaustion) go to humans with active triage. Informational alerts go to dashboards rather than inboxes. We tune the alerting during the first month of operation to reduce false positives — alert fatigue is the most common reason monitoring stops working.

Yes — our cloud database solutions service covers managed cloud database hosting on AWS, Azure, and Google Cloud, and our managed UK hosting service covers VPS and dedicated database hosting where self-hosted deployment makes sense. Maintenance retainers integrate cleanly with whichever hosting setup you have, including coordination with your existing cloud provider.

On ongoing maintenance retainers, response times are agreed in the SLA — typically within 1 hour for production-down incidents and 4 hours for severe-degradation incidents. For one-off audit clients, we accept emergency engagements on a best-effort basis. The fastest way to get fast response when you need it is to be on retainer before the incident.

Yes. We work on databases hosted with any provider — AWS, Azure, Google Cloud, Heroku, DigitalOcean, Supabase, Render, or self-hosted setups. The audit and optimisation work is independent of where the database lives. Where the hosting setup itself is limiting performance, we will tell you honestly and recommend the change — but we will not pressure you to migrate unless it genuinely matters.