Pitfalls when wiring TMDb API and Supabase through ISR
Get revalidation wrong and a free tier evaporates. Notes on putting a cache between an external API and a database.
Pull data from an external API, store it in a database, render it on a page. A common shape — but once there are two or more caching layers, “where did this go stale?” becomes surprisingly hard to answer.
What happened
Every page view was hitting Supabase, and the free-tier request count climbed faster than expected. The cause was mundane: pages with dynamic parameters had no revalidation interval set.
Sorting it out
Different data tolerates different staleness.
- Rarely changes (titles, release years) → long interval
- Changes occasionally (which service carries a title) → medium
- Should appear immediately (anything a user just entered) → don’t cache
Doing this classification per data type rather than per page makes the choice defensible. Reason per page and you end up saying “this page has both, so use the shorter one” — and everything drifts short.
Keep images off your own bandwidth
The other win was images. Optimizing a remote CDN image through your own server spends your bandwidth and your optimization credits. Referencing the original CDN directly dropped consumption visibly.
The takeaway
Caching isn’t only a performance mechanism — it’s a design constraint for staying inside a free tier. For solo projects, that second meaning bites first.