Xano · PostgreSQL · Performance
How I Made Slow Xano Endpoints 15× Faster (12 s → 0.8 s)
On a recruitment platform I built on Xano, some screens took up to 12 seconds to load. The database held 130k contacts, 100k companies, 35k candidates and 4k jobs. After three changes, the same endpoints answered in 0.8 seconds: 15× faster. Here's what I changed, so you can check your own Xano project for the same problems.
Why Xano endpoints get slow
Xano runs on PostgreSQL. When an endpoint feels slow, the cause is usually one of these:
- Filtering on columns without an index. PostgreSQL has to read every row to find matches. Fine at 1k rows, painful at 100k.
- Slow work inside the request. Calling an AI model or an external API while the user waits.
- Filters that don't match how data is stored, so the database can't use an index even when one exists.
My platform had all three.
1. Index the columns people filter by
The main screens filtered contacts and candidates by a handful of fields. Those columns had no indexes, so every request scanned the whole table.
I added indexes on the filter columns used by the slowest endpoints. This is the cheapest fix there is: no logic changes, just telling PostgreSQL how to find rows quickly.
Tip: start with the columns in your slowest endpoint's filters and sort order, not every column. Indexes also cost a little on every write.
2. Replace a boolean flag with an indexed type column
Contacts and candidates lived in the same table, separated by an is_contact boolean that the main lists filtered on.
I replaced it with a type column (contact or candidate) and indexed it, so the main lists could use the index.
Tip: a named type column also leaves room for a third kind of record later, without another boolean.
3. Move slow work to background jobs
The worst wait wasn't a query at all. When a candidate uploaded a CV, the endpoint parsed it with OpenAI and Google Vision before answering. That took 32 seconds.
I moved the parsing to a background job: the upload is saved and confirmed straight away (under 1 second), and the profile fills in when the job finishes. I wrote up that pattern in a separate article.
The result
- Key endpoints: 12 s → 0.8 s (15× faster).
- CV upload: 32 s → under 1 s.
Checklist for your Xano project
- List your 3 slowest endpoints.
- For each, note which columns it filters and sorts on. Are they indexed?
- Look for booleans or text fields every query filters on. Would one indexed column be simpler?
- Look for AI or external API calls inside the request. Can they run in the background?