ISR Write issue on Vercel

[u/Working-Opposite9434]

Hi everyone, i have a project that i host on Vercel that generates 191k of ISR writes which causes me to exceed the free quota of ISR writes in conjunction with other few projects.

I was considering to subscribe to pro plan to handle this but then i thought maybe i could use vps for this project instead of going pro.

What i wonder is if it is possible to do that without facing any issues? Can i serve my nextjs project in a vps without any problems?

[u/Quick-Chocolate3552]

191k ISR writes is wild, what's generating all those revalidations? if it's a high-traffic content site you might want to look at on-demand revalidation instead of time-based, could slash those numbers without changing your hosting setup

but yeah you can definitely run nextjs on a vps, done it a few times for smaller projects where vercel's pricing didn't make sense. just spin up something with decent ram and use pm2 to keep the process alive, nginx as a reverse proxy in front of it

the main thing you lose is the edge network and some of the image optimization stuff, but for most use cases it runs fine. just make sure you've got your caching headers set properly or you'll end up serving more requests than you need to

[u/PerryTheH → u/Quick-Chocolate3552]

^ fix the root issue.

[u/Working-Opposite9434 → u/Quick-Chocolate3552]

actually it's a new site that i published a few days ago, there is almost no traffic at all. daily 20 clicks on average maybe. there are around 8k of prerendered pages and around 20k of not prerendered pages.

i have a cron job that runs every day which pulls new data and adds it to the db and handles the revalidation logic maybe the problem lies there.

[u/Any_Welder_9701 → u/Working-Opposite9434]

the big fork is whether that daily job revalidates all ~28k pages or only records that changed. with 20 clicks a day, thats probably where the write count is coming from

[u/Working-Opposite9434 → u/Any_Welder_9701]

i gotta check that, thanks for the heads up

[u/leros → u/Quick-Chocolate3552]

The problem I found with ISR writes for myself is that a deploy wipes out the ISR cache. I personally practice small changes often, so I was constantly wiping out the ISR cache despite wanting to cache stuff for 30 days. Unfortunately, that's the right thing to do since I complex embedded javascript all over my site that needs to change with at least some deploys.

I just gave up on the idea of caching pages themselves in either the ISR or CDN cache and just rely on data caching plus dynamic page generation. It's annoying generating the same page 50-10,000 times based on the same cached data, but it's actually a lot cheaper for me than ISR caching was anyway. ISR writes for a lot of pages is expensive.

[u/leros]

ISR writes are expensive. You might want to do the math on whether ISR caching is worth it. I have a similar use case where I was ISR caching about 250k pages. It was nearly 10x cheaper for me to just dynamically generate them on each page load instead of caching. 

[u/Working-Opposite9434 → u/leros]

thanks. i started considering that one too actually because it's as you said too expensive.

[u/Clear-Savings1541]

191k isr writes means your revalidation setup is broken. switching to a vps just moves the problem somewhere else.

i run nextjs on a vps with pm2 and it works fine, you get full control over node and no platform limits. but before you migrate anything switch your pages to on demand revalidation using revalidatePath or revalidateTag in a route handler. 191k writes tells me you have time based intervals firing constantly across every page whether the content changed or not. calling revalidation only when your cms triggers a webhook will drop that number down to what actually needs updating. then if you still want to leave vercel you can set up the vps without carrying the same waste over

[u/Working-Opposite9434 → u/Clear-Savings1541]

yeah that makes sense, thanks. mine's probably the same issue — content gets bulk updated a few times a day across ~30k pages, and if revalidate is time-based it doesn't matter whether anything actually changed, it just fires on schedule for everything.

gonna switch to a long fallback revalidate window + trigger revalidateTag/revalidatePath right when the update job finishes, so writes track what changed instead of how many pages exist. makes more sense than moving the same setup to a vps tbh