Demo, all content is generated
Question

Pricing page still shows old prices hours after I change them in Supabase

Open · 331 views · asked by kimberly_j · edited

I change a price in the Supabase table editor and the live pricing page shows the old one for an hour or more. Locally it updates immediately. Claude Code put export const revalidate = 3600 on the page for "performance". I'm guessing that's related, but I also don't want to hit the database on every page view if that's bad?

What I’ve tried

Redeploying updates the prices, but I can't redeploy every time I change a price.

Comment

4 answers

dev_ana · edited

Yes, that line means "serve the cached page and rebuild at most once per hour". For a pricing page with a handful of rows, simply rendering it on every request is fine, a single indexed query is milliseconds. Remove revalidate and see if you even notice.

If you want to keep caching, do on-demand revalidation instead of a timer: a route handler that calls revalidatePath('/pricing'), and call it after you change a price.

Comment
if I change it in the Supabase table editor, what calls that route? kimberly_j · edited
hannah_reyes · edited

A Database Webhook in Supabase (Database → Webhooks) on UPDATE of your prices table, posting to https://yourapp.com/api/revalidate. Add a secret header and check it in the route, otherwise anyone can purge your cache. Then prices update within a second and you keep the caching.

Comment
Went with removing revalidate for now since it's simpler, will try the webhook when I have more traffic. kimberly_j · edited
mei_lin · edited

Middle ground: keep revalidate = 3600 but also call revalidatePath from the admin screen where you edit prices, if you build one later. Timer as a fallback, on-demand for the changes you know about.

Comment
sarah_k_dev · edited

Honestly for a pricing page with 3 rows, dynamic rendering is the answer. Caching is for when you have a measured problem.

Comment
That's what I ended up doing, glad to hear it's not lazy kimberly_j · edited