/01
Query plans you can read
EXPLAIN on the paths staff leave open — which index was used, and in which order the tables join.
Database
A database that stays quick as the lists grow.
We optimize the store you already run — MySQL or Postgres: slow queries, missing indexes, and reports that should not freeze checkout.
MySQL
Postgres
Indexes
Tuning
How we do this work
What you can expect from us.
This is database work, not a MySQL product. We look at the live store the product already uses — the list that takes three seconds, the month-end export, the checkout that waits on a scan. MySQL and Postgres are both normal. The first fix is usually a better index: a small set that many screens share, not one index on every column.
We start read-only. EXPLAIN shows how the server plans to join and which index it picked. ANALYZE (or ANALYZE TABLE) refreshes the stats the planner uses. Then we change one thing at a time so a report does not lock the storefront. Redis stays in the mix when speed needs a cache, not a second set of books.
What we ship
What this work usually includes.
/02
Indexes that match the WHERE
A short composite when one column is not enough. A covering index when the list can stay in the index and skip the table row.
/03
Fewer full scans
Large order and stock tables should not be read end to end on every click.
/04
Keys that fit the engine
A short primary key on InnoDB. On Postgres, indexes that match the filters you actually run — not a key for every column.
/05
Stats the planner can trust
ANALYZE so a plan is not built from last year’s numbers.
/06
Reads that do not freeze writes
Heavy reports moved off the live path. Memory sized to the working set you actually touch.
/07
One change at a time
An index or a query rewrite, with a way back, so Friday night is not the first test.
/08
A look after real traffic
When the lists grow, we come back to the same queries. Same team, same notes.
After it ships
What the team notices.
01
Checkout stays up
A report should not lock the sale.
02
Fewer wasted indexes
Extra keys slow inserts. We add the few that many lists share.
03
The store you already have
MySQL or Postgres on the invoice. Redis if the next step is a cache, not a new database.
Delivery
How we build it.
-
01
Read the slow work
A quiet look at slow queries, locks, and the pages staff leave open.
-
02
Read the plan
EXPLAIN before we touch an index. What the planner thinks it will do.
-
03
Tune one path
An index, a query rewrite, or a report that no longer runs on the live desk.
-
04
Check writes still breathe
Inserts and checkout after the change — not only the SELECT that got faster.
-
05
Watch a real week
The same lists, with real traffic. Then the next slow one.
Typical use
Where this lands first.
- Slow order lists
- Month-end reports
- Checkout waits
- Join-heavy screens
- Growing tables
- Stale planner stats
Related services
Pick a next page.
Questions
Questions teams ask first
- Do you develop databases?
- No. We optimize the store you already run. New tables still follow the same index rules when we add a feature — that is still tuning.
- MySQL or Postgres?
- Both. We pick from the brief. The same habits apply: read the plan, add few indexes, keep reports off checkout.
- What do you actually change?
- Indexes, the query the app sends, and sometimes when a report is allowed to run. We show the EXPLAIN before and after.
- Will more indexes always help?
- No. Unused indexes waste space and slow inserts, updates, and deletes. We add the few that many lists share.
- Can you work with our existing database?
- Yes. We start read-only, then suggest one index or one query change at a time.
Ready when you are
Talk about database optimization.
PHP, Node.js, React, or a mix. You get a tracking ID and a reply from the same people who will build it.