The report that used to be instant
Four seconds became forty after three years of data. The query is the same one written when the table held two thousand rows.
Services
The report the manager asks for takes forty seconds and the page times out first. Nobody changed anything — the table grew. Most database problems do not begin with a failure; they begin with a design decision taken when there were two thousand rows and nobody expected two million. By the time it hurts, three reports and one screen depend on that decision.
Four seconds became forty after three years of data. The query is the same one written when the table held two thousand rows.
A column is renamed in production on a Thursday night, and a week later an old screen fails for one customer.
There is a dump every night. Nobody knows how long restoring it takes, or whether the application still starts against it.
Orders by branch and month, indexed for the report that is actually run, not for the one in the diagram.
Same numbers, read from a summary table updated on write, and the accountant keeps the export format they already use.
Add the new column, write to both, backfill in batches, switch the reads, then drop the old one — each step reversible.
Restore last night's backup onto a second machine, start the application against it, and write down the minutes it took.
Fixed scope. Fixed price.
Agreed in writing before anything is built. You approve before we start.
Start from the report someone waits for every morning, not from the entity diagram drawn before the system existed.
Query plan, row counts, time of day. Guessing at the cause is how an index ends up on the wrong column.
Every migration is reversible, and the old column stays until the new one has survived a full month-end.
A backup nobody restored is a hope. The drill is part of the delivery, not an extra we offer afterwards.
Selected work
Published case studies connected to this service.
FAQ
What owners usually ask before requesting a quote for it.
Often yes: an index, a rewritten query, or a summary table. And sometimes no, because the screen reads the data in a way that cannot be made fast — we will say that before taking the work.
Sometimes the answer is an index, sometimes more memory, sometimes a schema that was wrong from the start. We measure, then say which. Hardware is the most expensive way to avoid a design decision.
The one that fits the workload and your team: PostgreSQL or MySQL on a server, SQLite where a single machine owns the data. Maxisoft runs on a local SQLite database on purpose, because the counter has to keep selling when the connection drops.
Then the first deliverable is documentation, and it is not free: reading an undocumented schema takes time. Occasionally rebuilding is cheaper than reverse-engineering it, and you get the cost of both before choosing.
Start a project
Send the brief. It comes back as a written scope and a fixed quote before anything is built.