All references

Production database optimisation

A Slovak SMS micropayment aggregator

Previous optimisations had not helped — the real cause sat at the boundary of the database and the application code. A targeted, reversible change cut the load with no downtime.

Challenge

The production database CPU sat at 50–60% for a long time, higher at daytime peaks. The client had already tried several optimisations with no effect and faced an investment in more powerful hardware.

Solution

We diagnosed with read-only access to production only. Combining query statistics, sampling of active connections, execution plans and a review of the application code, we found the root cause that the summary statistics were hiding — and removed it with a targeted, fully reversible change with no downtime.

Results:

• CPU load from 50–60% down to about 20% — cut by more than half
• The reduction holds long-term; the need for stronger hardware went away
• Deployed with no downtime, measuring the impact after each step (service by service)
• Diagnosis with read-only access only — no risk to the running system

A cause the statistics did not show

Most of the CPU was not spent processing data but on overhead — the database recompiled short, very frequent queries on every run, and the way the apps composed them made them impossible to cache. The overhead repeated non-stop for no benefit. Only direct measurement of what actually ran on the CPU, combined with reading the application code, revealed it.

Safely, in production

We disabled the overhead only for transactional application connections, service by service, measuring the impact after each step. Analytical connections, where it is justified, we left untouched. The change is fully reversible — exactly the approach that lets optimisation be done fast and with AI in the working process, yet always through evidence, not guesswork.