What it is
When your app looks something up, the database has to find it. With ten records it can read everything and it’s instant. With a hundred thousand, reading everything for every request is what makes a page take eight seconds, then give up. A database index is like the index at the back of a book: a way to find a record without reading every page. AI tools rarely add them, because the app is fast while it’s being built.
The same goes for lookups that fetch far more than the page needs: loading every order to show the latest five, or going back to the database once for each row in a list.
What it looks like from your side
The app was fast and now it isn’t. Dashboards that take longer every month. A launch day where sign-ups spike and everything slows down at once. Timeouts that come and go. A hosting bill that climbs because the database is working far harder than it should.
What it costs if you ignore it
A slow app during your launch is the launch. People who hit a timeout on sign-up don’t come back. And the fix people reach for under pressure, a bigger database plan, is expensive and doesn’t fix the cause. The real fix is usually a few indexes and a few rewritten lookups, but you need to know which ones.
How to check it yourself in 30 seconds
- Open the page in your app that shows the longest list: orders, users, messages. Note how long it takes to load. Then open the same page for the account with the most data, if you have one.
- If you use Supabase, open the dashboard and look for Query Performance under Advisors. It lists the slowest lookups and suggests missing indexes. Anything described as a sequential scan on a big table means the database is reading everything, and that’s worth asking about.
- If you don’t use Supabase, your hosting dashboard usually has a database page with charts. Look at how load and response time have changed over the last month.
This is read-only. Don’t run anything from these pages while you’re looking.
How I fix it
I find the lookups that actually run on your busiest pages, add the indexes they need, and rewrite the ones that fetch too much or repeat themselves.
Then I put realistic numbers of users through the core flow so you know where the next limit is, and note it in the report.
Find out before your users do.
The Production Readiness Review is $250, takes 2–3 business days, and ends with a clear verdict: fix, restructure, or rebuild.
Book the $250 review