Performance · queries
It was fast until it had real data in it
Nothing broke. The app just got slower every week until someone complained, and now a page that used to load takes eight seconds or times out. This is the most predictable problem in a generated app, because the code that is fast on ten rows and unusable on ten thousand looks exactly the same.
Tell us which screen is slow and roughly how many rows are behind it. That is usually enough to guess right before we look.
- First step
- A short call, or a written description if you would rather not talk yet
- Who you speak to
- The engineer who would do the work. No account manager, no sales call.
- Turnaround
- Most single problems are resolved within 48 hours of getting access
- Cost
- Quoted after we have seen it — scope varies, and guessing helps neither of us
How to get this fixed
Already a client? Raise it as a ticket in Golux Club and it enters the queue with an SLA attached.
Four causes, in the order we find them
A query in a loop: the page fetches a list, then fetches something for each item, so twenty rows means twenty-one round trips and two hundred rows means an unusable page. No index on the column you filter or join by, so the database reads every row to answer every request — invisible at a thousand rows, fatal at a hundred thousand. Selecting everything and every relation when the screen shows four fields. And no pagination, so the app asks for the whole table and the browser renders it.
How to tell it is this
- The network tab shows dozens of requests to the same endpoint on one page load
- It is slow in proportion to how much data the account has
- The Supabase dashboard reports slow queries or statement timeouts
- One screen is slow and the rest are fine
- It got noticeably worse after you imported real data
What we do
Measure, then change one thing at a time.
- 01
Find the actual slow part
The request waterfall and the database's own slow-query log. Guessing at performance wastes days; the measurement takes an hour.
- 02
Kill the loop
Queries in loops replaced with one query that fetches what the screen needs, in a single round trip.
- 03
Index what you filter by
The columns you actually query, including the foreign keys the generator left unindexed. Usually this alone is the difference.
- 04
Page it and prove it
Pagination or limits where the list can grow, then the same measurement again so you can see the before and after.
What you get
- The slow screen fast, with the before and after timings
- The indexes added, and why each one
- Any other query heading the same way, listed
- A note on what will be slow next, at ten times the data
When this is not what you need
- Everything is slow everywhere — that is architecture, and the honest answer is a review rather than a fix
- It is slow because the hosting is undersized; sometimes the answer is a bigger instance and we will say so rather than bill you to find out
- You want a performance budget and monitoring across the product — sprint work
How it works
- 01
Tell us the symptom
One paragraph is enough — the error, the screen, what you expected. Run the free audit first if you have not; it often names the problem for you.
- 02
A call, or a written reply
Thirty minutes to look at it together, or a written answer if you prefer. Either way you find out what it is before anything is agreed.
- 03
A written offer
After the call: the scope, the approach and what we need from you. Discussed on the call, confirmed in writing.
- 04
Fixed, explained, handed back
The fix in your project, a short note on what was wrong and why, and how to check it yourself — typically inside 48 hours of getting access.
What we promise before any money changes hands
We tell you what is actually wrong, whether it is one problem or a symptom of a bigger one, and what it would take — before you commit to anything. If the honest answer is that you can fix it yourself in an afternoon, that is the answer you get, and the instructions are usually on this page already.
Questions
- Will you have to change my database schema?
- Adding an index is not a schema change in any way that risks your data, and it is usually the whole fix. If the tables genuinely need restructuring, that is bigger than one fix, and you will hear so before anything is agreed.
- How much faster, realistically?
- For the two common causes — a query in a loop, a missing index — it is normal to go from seconds to under two hundred milliseconds. We measure before and after so you are not taking our word for it.
- Could it be the AI calls rather than the database?
- Often, and we check. An uncapped model call in a render path is slow and expensive at once; the fix is caching and moving it off the critical path, and it is covered by the same price.
- Is this priced per screen?
- Per problem. If three screens are slow for the same reason, that is one piece of work. If they are slow for three different reasons, you will hear that on the call rather than after the invoice.
Other things we fix at the same price
- Login works, no data shows“I can log in, but every list is empty and there is no error.”
- A secret key is in my bundle“There is a secret key in my JavaScript bundle.”
- The build or deploy is failing“The deploy fails, or it works in preview and breaks in production.”
Next step
Tell us the symptom. We will tell you if it is one problem.
We answer within a few hours with what it is, what it would take, and what we need from you. If it is bigger than one problem, we say that instead — before anything is agreed.
