Aurora MySQL · Performance and cost
Is Aurora MySQL slow or expensive?
Your application is waiting on the database, the Aurora bill is hard to explain, or adding capacity has not settled the question. I review one agreed problem and give your team findings, prioritised next steps and a plan for testing them.
When a focused review helps
This is for software and product teams running Amazon Aurora MySQL on AWS, with a technical owner who can provide evidence and carry out the recommendations. Useful starting questions include:
- Why are particular queries or application requests slow?
- What is behind recurring lock waits or uneven response times?
- Is more database capacity the right response to the workload?
- Which parts of the database workload and configuration should we investigate before making a cost decision?
We agree which question to investigate. The review follows the evidence available for your environment; it is not a general review of every AWS service or charge.
What the review can examine
The scope may include the following, where they help answer the agreed question:
- Query examples, execution plans, indexes and transaction behaviour.
- Workload patterns, resource use and relevant database configuration.
- How the application uses connections and the database instances in the cluster.
- Database usage and cost information supplied by your team, considered alongside the workload and the constraints on changing it.
Findings distinguish observations from hypotheses. A recommendation to change a query, an index or capacity comes with prerequisites and validation steps; a lower bill or faster response is not assumed.
What you receive
A written report and a technical handover, covering:
- The question investigated, the agreed scope and the evidence reviewed.
- Findings, their limitations and any remaining uncertainty.
- Prioritised recommendations and the trade-offs your team needs to consider.
- Checks your team can run to compare performance and cost before and after a change.
- Missing evidence and the next useful investigation, where the question cannot yet be answered.
Your technical owner decides which recommendations to implement and validates the result in your environment.
Scope and process
This is the MySQL & Aurora Performance Diagnostic applied to an Aurora MySQL question.
If your question is about how the cluster is laid out rather than one slow or costly workload, see the Aurora MySQL architecture review.
- Describe the database, the symptoms or cost concern, and the decision your team needs to make.
- Agree the principal question, evidence requirements, effort limit, deliverables, fee and schedule.
- Review the evidence and write up findings, recommendations and uncertainties.
- Walk your team through the result and the validation steps.
One environment and one principal question, with the scope, fee, and schedule agreed before work begins.
Fixed fee, agreed after a short scope review.
Evidence and access
Start with a high-level description of the system, what is slow or unexpectedly expensive, and what you need to decide. Evidence requirements are agreed after that first conversation. They may include sanitised queries, plans, metrics, configuration and relevant database cost summaries.
Production access is not always necessary. Any access and the way technical evidence is shared are agreed before work starts. Please do not send credentials, customer data, connection strings or sensitive logs with your enquiry.
Work you can inspect
The sample MySQL diagnostic shows the report structure using a synthetic Aurora MySQL 3 scenario, with no customer data or measured performance results. Its findings are illustrative, not a result promised for your database.
An anonymised MySQL audit examines full scans, long procedures and idle transactions. It describes the evidence and recommendations for that system; it is not an Aurora cost-saving case study.
Not included
- Production changes or implementation of recommendations.
- Continuous monitoring, managed operations, emergency response or on-call cover.
- An open-ended investigation or a review of the whole AWS account.
- Guaranteed performance improvements, cost reductions or root-cause certainty.
Your team owns testing, change approval and deployment. Any further involvement requires a separate, explicitly agreed scope.
Questions
Can the review help if the main concern is cost?
Yes, where the question concerns the Aurora MySQL workload and the choices around it. We agree which usage and cost evidence is needed and what decision the review should inform. It does not promise savings or cover unrelated AWS spending.
Do you need direct production access?
Not necessarily. The review can start from evidence your team collects. If direct access would help, its scope and the handling of data are agreed before work starts.
What if the evidence is incomplete?
The report states what could and could not be established. It identifies missing evidence and useful next checks rather than treating an assumption as a finding.
Will you make the changes?
The diagnostic delivers findings, recommendations, validation steps and a handover. Your team implements and tests the changes. Hands-on work would require a separate, explicitly agreed scope.
How are the fee and schedule agreed?
After a short fit and scope review, you receive a written proposal with the environment, effort limit, evidence requirements, deliverables, fixed fee and schedule. Work starts once that is agreed.
Is this suitable for an incident happening now?
No. This is scheduled work. If a system is failing now, your on-call team or platform provider's support is the right first contact.
Have an Aurora performance or cost question?
Describe the system, the concern and the decision you need to make. Include who will own the next steps in your team. A high-level description is enough to start.