Database Health Audit · Fixed Price · Results in Five Working Days
Your database is probably the reason your system feels slow
Slow queries, bad indexing, duplicate data, and structural problems accumulate silently until they cannot be ignored. Our in-house database expert Simon digs through the structure, the queries, and the indexes, then tells you exactly what is wrong and how to fix it. Plain English. No jargon. No disruption to your live system.
Trusted by:
The signs your database needs attention
Database problems rarely announce themselves clearly. They creep in over months or years as data accumulates, queries get added, and nobody has time to look under the bonnet. By the time the symptoms are obvious, the underlying issues have usually been building for a long time.
If any of the following sounds like your system, there is almost certainly a structural issue worth investigating. The good news is that most database problems are fixable, and fixing them has an immediate and measurable effect on performance.
Reports that used to be instant now take minutes
When a query that ran in seconds starts taking minutes, it is rarely the query that changed. It is usually a missing index, a table that has grown beyond what the query planner expected, or a structural issue that was hidden by smaller data volumes.
System slowdowns at peak usage times
Everything runs fine with two users. Under real load it crawls or crashes. This is almost always a locking issue, a missing index on a frequently queried column, or queries that are competing for the same resources inefficiently.
Database growing much faster than it should
If your database is growing significantly faster than your actual data volume suggests it should, you are almost certainly storing duplicate records, orphaned data, or audit trails nobody has thought to manage.
Unpredictable behaviour and occasional errors
Queries that sometimes work and sometimes do not. Errors that appear intermittently with no obvious trigger. These are often the hardest symptoms to diagnose because they are rooted in race conditions, constraint violations, or data integrity issues that only manifest under specific circumstances.
Developers spending time on performance rather than features
If your development team is regularly fielding "why is this slow" tickets rather than building new functionality, the database structure is pulling them into a reactive loop that good architecture would prevent.
A database nobody fully understands anymore
Every system grows beyond its original design. Tables get added, columns get repurposed, relationships get implicit rather than enforced. Eventually nobody is entirely sure what relates to what or why some tables exist. That uncertainty is a risk on its own.
What Simon checks during the audit
A comprehensive review across every layer of your database, from structural design to query execution.
Schema and structural design
How tables are structured, how relationships are defined, whether normalisation is appropriate for your use case, and whether the design matches the queries being run against it.
Index analysis
Which indexes exist, which are missing, which are redundant or overlapping, and which are actively harming write performance without providing adequate read benefit. Index problems are the single most common cause of performance degradation.
Slow query identification
Using query execution plans and performance logs to identify the specific queries causing the most damage. Not just which queries are slow, but why they are slow and what would make them fast.
Locking and concurrency
Identifying locking patterns that cause queues under concurrent load, transactions that hold locks longer than necessary, and deadlock risks that have not yet manifested but will under higher traffic.
Data quality and duplication
Duplicate records, orphaned rows, constraint violations, and data that should have been cleaned up but has not. These affect both performance and the reliability of anything built on top of the database.
Storage and growth analysis
How much space each table and index uses, which objects are growing fastest, and whether the growth patterns indicate a structural problem or simply increasing data volume.
Configuration review
Database server configuration: memory allocation, buffer pool sizing, connection limits, and other settings that affect performance independently of schema design. Often overlooked but frequently impactful.
Security and permissions
User privileges, exposed sensitive data, and configuration settings that represent security risks. Not the primary focus of a performance audit, but flagged where found.
Benchmark and baseline
A before-state measurement across key queries and operations so you can measure the improvement after fixes are applied. Recommendations without a baseline are opinions. Recommendations with one are evidence.
Four steps from booking to clear action plan
The whole process is designed to give you maximum value with minimum disruption. Simon handles it personally throughout.
Review
You give Simon secure read-only access to your database. No changes, no disruption to your live system. He reviews the structure, configuration, indexes, and query logs to build a full picture of what is actually happening.
Analyse
Simon runs a series of checks across all the areas above: query execution plans, index coverage, locking patterns, data quality, growth trends, and server configuration. Think of it as an MOT for your database, done properly.
Report
You receive a plain-English report within five working days. It covers what is wrong, why it matters, and how to fix it. Findings are prioritised by impact so you know what to tackle first and what can wait.
Call and Next Steps
Simon walks you through the report on a short call. You can ask questions, challenge findings, and agree priorities. You leave the call knowing exactly what needs doing and in what order.
Handled personally by Simon, our in-house database expert
One person handles your audit from start to finish
The database health audit is not a product run through an automated tool that generates a generic report. Simon does the work himself: the analysis, the diagnosis, the report, and the follow-up call. The value of this is that when he finds something unusual or unexpected, he investigates it properly rather than flagging it as an anomaly and moving on.
Simon has worked on databases across a wide range of sectors: publishing, fashion ecommerce, professional services, manufacturing, and more. He has seen most of the ways databases accumulate problems and most of the fixes that work. The report you get reflects that experience rather than a set of automated checks.
- MySQL and MariaDB specialist
- Experience across high-volume transactional databases and reporting systems
- Part of the permanent Dev Partners team, not a contractor
- Plain-English communication: findings are explained, not listed
- Available for follow-on work if the audit identifies problems you want us to fix
- Full schema and structural review
- Index analysis and recommendations
- Slow query identification and diagnosis
- Locking and concurrency review
- Data quality and duplication check
- Storage and growth analysis
- Server configuration review
- Before-state benchmarks
- Plain-English report within 5 working days
- Follow-up call with Simon
- Prioritised action plan
If the audit does not find anything worth fixing, we will tell you that clearly. We are not going to manufacture recommendations to justify the fee.
The businesses that get the most from a database audit
The audit is relevant for any business running an application or system built on MySQL, MariaDB, or a similar relational database. These are the most common situations where clients come to us.
Bespoke Software Customers
Systems that have grown beyond their original design
Custom software built three or four years ago works well until the data volume reaches a point the original schema was not designed for. If your bespoke system is slowing down as usage grows, the database is the most likely cause.
eCommerce Retailers
Shopify back-end and ERP databases under strain
High-volume order processing, returns management, and stock synchronisation put real strain on database infrastructure. Particularly relevant for retailers running custom back-office systems connected to Shopify.
CRM Users
Custom CRM or CoreCRM installations getting slower
CRM databases accumulate contact records, activity logs, and historical data rapidly. Without periodic attention to indexing and query optimisation, what was fast at 10,000 records becomes sluggish at 500,000.
Pre-Rebuild Planning
Before starting a major development project
If you are planning to rebuild or significantly extend a system, understanding the current database structure before you start is far cheaper than inheriting its problems mid-build. The audit gives you a clear baseline and flags anything that would cause problems during the migration.
What the report actually looks like
The report is written to be read by the person making the decision about what to fix, not just by a developer. Plain English throughout, technical detail where it is genuinely needed.
The report covers
- ✓ Executive summary: what we found and what it means in plain English
- ✓ Schema overview: how your database is structured and where the design has gaps
- ✓ Index findings: what is missing, what is redundant, and what to add or remove
- ✓ Slow queries: the specific queries causing problems and why
- ✓ Data quality issues: duplicates, orphans, constraint violations
- ✓ Storage and growth: where space is going and whether it is a concern
- ✓ Before-state benchmarks: baseline measurements for comparison after fixes
- ✓ Prioritised action plan: what to fix first, second, and what can wait
What it is not
The report is not an automated scan output dressed up with a cover page. It is not a list of every possible improvement regardless of impact. It is not written in a way that requires a DBA to interpret it.
The findings are ranked by how much difference fixing them will make to your system's actual performance. Quick wins that take an hour to implement are separated from structural changes that require planned downtime.
After the audit
If you want us to implement the fixes, we can quote for that separately. If you want to handle it in-house, the report gives your team everything they need to do so. There is no obligation to engage us further.
Questions about the database audit
What clients typically ask before booking.
Simon works with read-only access. He cannot modify, delete, or write anything to your database during the audit. The access is purely for analysis: viewing structure, running EXPLAIN queries, reading slow query logs, and checking configuration. If your database is production-critical, we can also work from a copy or a replica if you would prefer.
We sign an NDA before any access is granted and the access credentials are removed at the end of the engagement. We treat client data with the same care we apply to our own.
Our primary expertise is MySQL and MariaDB, which covers the vast majority of web applications, bespoke software systems, and CRM platforms. These are the databases underlying most Laravel, CodeIgniter, and WordPress-based systems, as well as the majority of custom PHP applications.
If you are running PostgreSQL, Microsoft SQL Server, or another relational database, get in touch and we will let you know honestly whether the audit is a good fit. We are not going to take on a project where we cannot deliver the same quality of analysis.
Minimal, in almost all cases. Read-only analysis queries are lightweight and run at off-peak times where possible. EXPLAIN plans on slow queries add no measurable load. The only situation where there might be any impact is reviewing very large tables with missing indexes, and even then the effect is marginal compared to the queries your application is already running.
We will discuss the approach with you before starting, and if your system is particularly sensitive to additional load, we will work from a replica or a recent backup copy instead.
We will say so clearly in the report. A clean audit is a genuinely useful result: you have confirmation that your database is well-structured and performing as it should, with a baseline measurement to compare against in future.
In practice, we rarely complete an audit without finding something worth addressing. The nature of database systems is that problems accumulate gradually rather than appearing all at once. Even well-maintained systems typically have a handful of improvements worth making. But if yours is the exception, we will not manufacture recommendations to justify the fee.
Yes. After the audit, if you want us to carry out the recommended changes, we quote for that work separately. The audit fee covers the analysis and report only. Implementation is scoped based on what the audit finds: some fixes are a few hours of work, others require careful planning around schema changes that need downtime or testing.
Many clients handle the quick wins themselves using the report and bring us in for the more complex structural changes. That is a perfectly sensible approach and the report is written to support it.
Tools like MySQLTuner, Percona Toolkit, or the built-in MySQL slow query log can surface useful data, but they generate output rather than insight. They will tell you that a table has no indexes and some queries are slow. They will not tell you why the schema is designed the way it is, whether a proposed index would actually help the specific queries you run, whether the slow queries are structural problems or application problems, or how to prioritise the fixes by real-world impact.
Simon's analysis applies experience and judgment to what the tools surface. The recommendations in the report are based on understanding your specific system, not on running a standard script and formatting the output.
If your application is running slowly and you have not ruled the database out, the audit is a good starting point. Database issues are the most common cause of application slowdown in systems that have been running for more than a year or two, and they are among the most cost-effective to fix.
If Simon's analysis shows the database is healthy, the report will say so and will note any other likely causes based on what he observed during the access. That gives you a clear direction for the next investigation. Either way, you have removed the most likely culprit from the list.
What Our Clients Say About Us
“I have been working with the team at Dev Partners for the last 3 years and we have always been impressed with the speed in which they act on things for us, along with the honest open communication we have between us. The team are a valuable and vital part of our supply chain and we look forward to continuing to work together for many years to come.”
Ready to find out what is slowing your system down?
Book your audit and have a clear action plan within five working days.
Fill in the form and we will be in touch to arrange read-only access and get started. The whole process requires minimal input from you beyond the initial access setup.
What you get:
- Secure read-only access only, no changes made to your system
- Full analysis by Simon, our in-house database specialist
- Plain-English report delivered within five working days
- Prioritised action plan ranked by impact
- Follow-up call to walk through the findings
- Before-state benchmarks to measure improvement against
Fixed price: £495 + VAT
No hidden extras, no scope creep. If the audit finds nothing actionable, we will tell you that clearly.
Book Your Database Audit
Tell us about your system and we will be in touch within one working day to arrange access.
