The query was correct when the table had a few thousand rows. It is still correct at a few million. The planner stopped using a shortcut and started reading the table. That is an index problem, not a “the app is old” problem.
Why website speed affects revenue is about what the browser does: weight, LCP, the wait on a phone. A strong Lighthouse score does not index your bookings table. This article is the database time inside that wait.
What an index is for
An index is a side structure the planner can use to find rows without reading all of them. A filter on branch and start time wants an index that leads with those columns. An index on created_at does not help that filter just because it exists.
PostgreSQL’s index documentation is the reference we use when the engine is Postgres. The habit is the same on MySQL: read the plan, do not guess. Which engine you are on is the earlier decision in PostgreSQL or MySQL.
How you know
EXPLAIN the statement that the slow screen actually runs. EXPLAIN ANALYZE belongs on a copy or a quiet window, not as a reflex against production during a sale.
A sequential scan of a large table, for a filter that should return a handful of rows, is the smell. A scan of a 200-row settings table is fine. Indexing every column is how writes get slower: every insert maintains every index.
What we change
- Capture the statement from the slow screen or the slow-query log. Not a hunch about “the database.”
- Read the plan.
- Add the index that matches the filter and the sort.
- Confirm the plan changed.
- Drop indexes nothing uses.
If the plan is already an index lookup and the screen is still slow, the time is somewhere else: a chatty API, a missing cache, or the browser work in the speed article. Another index will not fix that.
Straight next step
If one named screen got slower after a year of real data, send the query. We will read the plan before anyone rewrites the page.
