Project backend-stabilise-one-service-data-layer · revised 11 October 2026
Project
Stabilise the data layer of one service: slow queries, N+1, indexes and connections
We agree a defined list of data-layer problems in one service, measure it, and return the whole list as accepted, tested changes with a closing before and after measurement.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the list, the price and the terms in writing.
The result you are buying
A busy service accumulates data-layer faults at once: a handful of slow statements, endpoints that run a query per row, indexes nobody reviewed, a pool that runs out under load, and sometimes a lock cycle. Each looks like a different job, so they get patched one at a time with no shared baseline, and nobody can say whether the service as a whole got better.
Who it’s for: An engineering manager or founder whose one core service has a data layer that keeps producing slow pages, timeouts and connection errors.
Usually starts when: Several different database problems have piled up in one service, each too small to schedule alone and together too large to ignore, and a launch, a funding round or a new hire makes stability matter now.
The result: You buy the finished list for one service. Every agreed item is fixed, measured and accepted by you or removed in writing, and a closing measurement on staging shows the agreed targets for slow statements, query counts and connections.
How the work fits together
The project is complete when you accept the agreed list: every item on it has been accepted by you or removed from the list in writing, and the closing measurement meets the targets recorded for the list. You accept the finished list, not each internal step.
Set up off-site backups for a website and prove a restore works Job First
Back up one site and its database to a storage account you own, then restore a copy on staging and test pages and a record before signing off.
If you have no backup you have restored successfully, a tested restore point comes first, so every later change has a way back.
Review the indexes in one database and apply the agreed changes, measured Job Each time it fires
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.
One pass for the database, if the baseline shows missing or unused indexes
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.
Up to four statements on the agreed list, chosen from the baseline
Fix one endpoint that runs hundreds of queries, and prove the query count Job Each time it fires
One endpoint stops issuing a query per row: its database query count drops to an agreed ceiling and a test fails if it climbs again, with identical response data.
Up to three endpoints on the agreed list, if the baseline shows a query per row
Stop "out of database connections" errors in one service, pool budgeted and tested Job Optional
One service that times out waiting for a database connection, or hits the server limit, is diagnosed and corrected, then completes a load test at the concurrency you name.
One, if the baseline shows connection errors
Find why two parts of your app deadlock, and make that workload run clean Job Optional
One workload that fails with a database deadlock or lock wait timeout is reproduced on staging, its lock order or transaction scope corrected, and a concurrent test shows it clean.
One workload, if the baseline shows deadlocks or lock timeouts
Add a column to a large table and backfill it safely, with a rehearsed rollback Job Optional
One new column is added to a large PostgreSQL or MySQL table and backfilled in batches on a staging copy under write load, rows written meanwhile also get the value, and a rollback is actually run.
One change, if a fix needs a new column
Keep your database healthy: a slow-query and growth review every month Standing service Optional
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.
To keep the result: a monthly review of statements and growth after the project ends.
How an engagement works
The price covers the agreed list only. Items added later are quoted separately, and items found to be bigger jobs are re-scoped with you.
How it starts
You describe the symptoms and send the framework and engine versions, with no data or code.
We read the first export and the run instructions, and propose a baseline measurement on staging.
We take the baseline and propose the list of items, their targets and a fixed price. Nothing starts before you agree in writing.
We work through the list, sending a pull request or script with evidence for each item to accept.
We repeat the measurement, send the final summary and hand over anything left open.
Who decides what
You decide what is on the list and accept each item. Your team merges, applies scripts and deploys on its own gates, after a restore point it has tested.
Handover
Each accepted item arrives as a pull request or script with its evidence and undo step. Anything left unfinished is handed back with notes.
Sharing your product safely. Send symptoms and versions only. After you agree the project, invite us to a repository or fork you control and provide a staging database with personal data removed, never real customer data.
What is included, and what is not
- The opening baseline and the closing measurement, side by side
- A pull request or script for each accepted item, with its evidence and undo step
- A final summary: items accepted, removed or found to need a bigger job
- Read-only monitoring queries for the figures that matter, so you can repeat the measurement
Included
- One service and its one PostgreSQL or MySQL database
- An opening measurement on staging under a load profile you agree, giving the baseline for slow statements, query counts and connections
- A written list of items chosen from that baseline, each with an acceptance target and a fixed price for the list
- A closing measurement with the same profile, and a final summary of each item and how it ended
Not included
- Running scripts or changes against production, which stays with your team after a tested restore point
- Items added after the price is agreed, unless you add them to the list in writing
- Moving to a different database engine, sharding, or re-architecting the service
- More than one service or database
- A guarantee of production speed or capacity beyond the measured profile
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every item on the agreed list is either accepted by you or removed from the list in writing.
Evidence: The final summary, with your acceptance or removal recorded for each item.
The closing measurement, taken with the same load profile as the opening one, meets each target recorded for the list.
Evidence: The opening and closing measurements side by side.
Each changed statement returns the same rows as before, and each changed endpoint returns the same response.
Evidence: The comparison output attached to each item.
Each item that changes the database has an undo step that has been run on staging.
Evidence: The staging log of each undo.
Sign-off. You accept each item, or send it back with comments, and then you accept the finished list.
If it fails. An item we cannot bring to its target is named with the reason and what it would take, and is taken off the list with a matching change to the price. Nothing is billed as delivered that you have not accepted.
When it fits, and when we stop
It fits when
- PostgreSQL or MySQL on a version you can name, behind a Django, Rails, SQLAlchemy or JVM service
- The service runs on staging with a load profile and synthetic or anonymised data of realistic size
- Statement statistics or the slow query log have collected evidence from real traffic
- A named person can accept each item and apply changes
We stop and tell you if
- The service cannot be run on staging with realistic data volume
- No restore point exists that you have restored successfully, and none can be arranged
- Most items turn out to be caused by the application's design and need a rebuild, so we propose a different scope
- Nobody on your side can accept changes
What could go wrong
Every item is a separate pull request or script with an undo step, so any one can be reverted on its own. If the project stops, accepted items stay accepted and the rest is handed back with notes. Nothing is applied to production by us.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Fixing one item hides or worsens another, such as an index that slows writes. | Each item carries its own measurement, including write cost, and the closing measurement repeats the whole baseline. |
| The staging load profile does not resemble production. | The profile is agreed in writing from your traffic figures, and the summary states what it does and does not cover. |
| The list grows while we work. | The price covers the agreed list. Additions are written in and quoted, never absorbed silently. |
Each change is reviewed separately from the work that produced it, with particular attention to anything that changes data or schema, and you accept every item. No human supervisor is included unless your proposal names one. At launch the work is largely automated, and we say so.
Stays with a person
- You accept each item
- You merge, deploy and apply scripts on your own gates, after a tested restore point
Access we would need
- Read access to a repository or fork you control; no production access
- Staging copies with personal data removed or replaced
Questions
Do I buy tickets or a result?
A result for one service: an agreed list, each item measured and accepted, and a closing measurement against targets.
What does the project add to buying the jobs one by one?
The jobs fix individual causes. The project adds one opening baseline and one closing measurement of the whole service under the same agreed load profile, so you can see whether the service as a whole got better and whether one fix undid another, such as an index that slows writes. It also adds one list with targets and one acceptance. The starting price is the included jobs at their own starting prices plus that measurement and summary, so the saving is in coordination, not price. The price is a hypothesis we want to test.
What if the baseline shows the service needs a rebuild?
We tell you, with the evidence, and propose a different scope. You are not billed for work that does not meet the agreed targets.
How is this different from the monthly review?
This is a defined body of work that ends. The monthly review is a standing service that keeps watching afterwards.
Send an enquiry
Send us
- The framework and database engine with versions, and what the service does
- The symptoms you see: which pages are slow, which errors appear and when
- Whether statement statistics or the slow query log are collecting, and since when
- Do not send credentials, code or real data in the first enquiry
Later, once you agree
- A repository or fork you control, with run instructions and the tests
- A staging database restored from a backup with personal data removed or replaced, and a load profile to apply
- Exports of statement statistics and connection counts, with literal values removed
- The date of your tested restore, and a named person to accept each item
Your databases, queues, code and credentials stay yours. We work on staging copies you prepare, with personal data removed or replaced, and hand every change back as a pull request or script. We never ask for production passwords, and we do not connect to production. You apply changes after a restore point you have tested.
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 “backend-stabilise-one-service-data-layer” as the subject.