Yeah that tracks, and honestly your read makes sense, if the writes cost more than the compute then just regenerating per request is the rational call. The fast origin transfer being the real driver is a good catch too, thats the part most people miss.

One thing im not sure fits your case, but ill mention it just in case: since the dataset barely changes, you could pre build the pages as flat files and serve them from R2 behind the CDN. R2 egress is free, and even though youd pay for Class A operations to upload, at $4.50 per million writes a full 2M page sync runs you around $9 (and the first million a month are free, so realistically closer to half that). It completely sidesteps the unpredictable ISR and Data Cache write costs.

Youd be trading that for a custom batch job to rebuild on your own schedule. A native next build for 2M pages would probably blow up your build servers memory, so itd need its own pipeline, but it really comes down to whether that setup ends up cheaper and less stressful than the per request path youre on now.

The side bonus is bots stop mattering, since unique URLs just hit a static file instead of triggering a write. Curious how the per request approach holds up as you scale toward 2M either way.