Standing service sql-database-health-review-each-month · revised 11 October 2026
Standing service
Keep your database healthy: a slow-query and growth review every month
Each month we read your slow-statement and table-growth exports, report what changed, and prepare one agreed fix as a script or pull request for you to apply.
This starts a conversation by email. Nothing is charged, and nothing is reviewed, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Databases degrade quietly. A statement that was fast on small tables becomes the top consumer of time, a table and its indexes grow past the disk plan, dead rows pile up when cleanup cannot keep pace, and the usage counters that would show an unused index start again after a MySQL restart, or after a PostgreSQL crash or restore. Without a regular look, the first sign is an outage or a user complaint, and by then there is no baseline to compare with.
Who it’s for: A founder or engineering lead whose database has no owner: nobody looks at it until it is slow or full.
Usually starts when: The database has grown for a year or more with no regular review, or a past slowdown or full disk was noticed only when users complained.
The result: Each month you receive a written review of your slowest statements and your largest tables and indexes against the last month and your agreed thresholds. One recommended change a month arrives as a script or pull request with its staging measurement and undo step, the other findings as written recommendations, and you decide what to apply.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A review date each month is agreed in writing before it starts, set to what a service at this stage can keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer round-the-clock cover.
What must remain true
- The slowest statements and the largest tables and indexes are reviewed every month against the previous month and your thresholds
- Each finding ends as a recommendation, a prepared change or a note that it was left alone, with the reason
What we watch
- The monthly export of statement statistics or slow-query summary, with literal values removed
- Table and index sizes, dead-row indicators and connection counts exported by your engineer
- Your thresholds and the changes you have applied since the last review
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A statement's total or average time rises past the agreed threshold from one month to the next. | We read its plan on a staging copy and prepare a fix with measurements, as the one prepared change for the month. Priced as: Fix one slow query |
| Index usage evidence over a representative period (one that covers your longest regular job, such as a monthly close) shows an index to add or consider dropping. | We add it to the written findings with its evidence period. One index change, measured on staging with an undo step, can be the month's prepared change; a larger pass with up to five measured changes is the separate index review job. Priced as: Index review, applied and measured |
| A table or its indexes grow faster than the size line you agreed, which is the threshold written in the agreement. | We report the trend and the estimated date the threshold would be reached, and what could change it. |
| A month ends. | We send the written review and the log of findings. |
We do on our own
- Read the exports and compare them month on month
- Reproduce and measure a statement on a staging copy you provide
- Open a pull request or write a script with an undo step, one a month
We ask you first
- Anything that changes your database, its settings or its schema
- A second prepared change in the same month, or a full index pass, each quoted or bought as its own job
We escalate to you when
- A finding suggests data loss, corruption or a full disk within the next few weeks
- The statistics have been reset or lost, so a comparison is no longer sound
- Findings keep recurring because a recommended change was not applied
How you know it held. Each month the review shows the top statements and table sizes beside last month's, so you can see whether the database got better or worse, and each recommendation shows its evidence and undo step.
How we keep it true
This service is never finished. Each month's review shows how the database changed, and it continues until you end it.
Make one slow database query fast, with before and after plan evidence Job Each time it fires
One slow PostgreSQL or MySQL query meets a time you set on a staging copy, with the before and after execution plans and an identical-rows check attached.
One prepared change a month, as agreed
The month's prepared change is the job you can buy on its own, included in the monthly fee. A second change in the same month is bought as that job at its own price.
Review the indexes in one database and apply the agreed changes, measured Job Optional
The indexes of one PostgreSQL or MySQL database are reviewed against its real queries; up to five agreed changes are applied on staging and measured before and after.
Bought separately when the evidence supports a larger pass; not part of the monthly fee
A full index pass, with up to five measured changes, is the job you can buy on its own. One index change can be the month's prepared change instead.
What is included, and what is not
- A written monthly review with the changes since last month and a recommendation of act, watch or leave for each finding
- A growth table with the dates on which agreed size thresholds would be reached at the current trend, labelled as an estimate
- One script or pull request a month, with its staging measurement, undo step and the evidence behind it
- A running log of findings and what happened to each
Included
- One PostgreSQL or MySQL database reviewed once a month from exports you supply
- Top statements by total and average time, compared with the previous month
- Table and index size trends, dead-row indicators and connection peaks against thresholds you set
- One prepared change a month, for one statement or one index, as a script or pull request measured on a staging copy and with an undo step; a second change, or a full index pass, is quoted or bought as its own job
Not included
- Applying any change to your database; you review and apply every change
- Out-of-hours monitoring or paging, and any response-time guarantee
- Server provisioning, backups or restore testing
- Application code changes other than the agreed pull request
- A staging copy that holds real personal data; we decline it, and the copy must have personal data removed or replaced
- More than one database per subscription
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month's review lists the top statements by total time from the export you supplied, with the change since the previous month.
Evidence: The written review, which you can compare with your own export.
Every growth projection states the data and period it used and is labelled as an estimate.
Evidence: The growth table and its notes.
Every recommended change comes with its evidence, its staging measurement and an undo step, none is applied by us, and no month has more than one prepared change.
Evidence: The script or pull request attached to the review.
Sign-off. You read each monthly review and accept or send back each recommendation. A recommendation counts as delivered when you accept it.
If it fails. If a month's review cannot be produced because the export is missing or unusable, we say so and that month is not billed. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- PostgreSQL or MySQL on a version you can name, with statement statistics or the slow query log switched on
- Your engineer can produce the monthly export, or run the read-only script we supply, and send it with literal values removed
- A staging copy can be prepared when a fix needs a measurement
- Someone on your side reviews and applies changes
We stop and tell you if
- Statement statistics or the slow query log cannot be enabled
- Exports cannot be produced without including customer values
- The database is outside PostgreSQL and MySQL
- Most findings need changes you will not or cannot make, so the review has no outcome
What could go wrong
Every prepared change comes with an undo step, and you apply nothing without reading it. Ending the service leaves your database exactly as it is, with an open pull request finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A statistics reset hides a month of usage and a recommendation rests on too little evidence. | Each review states when the counters were last reset, and a finding based on a short period is marked watch, not act. |
| Growth estimates are read as promises. | Every projection is labelled an estimate, shows the data behind it and says what would change it. |
| Exports leak customer values. | The export route is agreed to carry statements with literal values removed, and a leaked value is deleted and reported. |
Each prepared change is reviewed by someone separate from the work that produced it. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and apply every change
- You approve the staging data and each thresholds change
Access we would need
- A monthly export from read-only statistics views, supplied by your engineer
- A staging copy when a fix needs a measurement
Questions
Do you connect to our database each month?
No. Your engineer sends an export, or runs a read-only script we supply that writes it somewhere you control. We hold no connection to production.
Can you promise we will not run out of disk?
No. The growth table is an estimate with its assumptions stated, and an alert on your own monitoring is still needed.
How is this different from the index review?
The index review is one pass over the indexes, with up to five measured changes. This is a standing monthly review of statements, growth and connections, with one prepared change a month. It can recommend an index pass when the evidence supports it, which you then buy as that job.
Also part of
Send an enquiry
Send us
- The engine and version, the database size and the largest tables
- Whether statement statistics or the slow query log are on, and for how long
- Any thresholds you already have, such as a disk limit or a worst acceptable query time
Later, once you agree
- A first export and a read-only script or query list that your engineer will run each month
- A secure route for the monthly export that carries no customer values
- Your thresholds, in writing, and the name of the person who receives each review
Your database, queues, hosts and credentials stay yours. Your engineer sends us exports with literal values removed, or runs a read-only script we supply that writes the export to a place you control. We hold no connection to your production systems. Every change reaches you as a pull request or a script that you review and apply.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “sql-database-health-review-each-month” as the subject.