Summary: Usage-based SSR platforms bill every request, so cost grows faster than traffic. This article explains the structural reasons, then shows the measured gr8s figures: about 5x fewer servers, lower memory and lower energy for the same workload.
Why SSR bills grow faster than users
On a usage-based platform, every page load, API call and server action runs your code on someone else's machine and is billed. That is convenient, but it means the cost curve tracks traffic almost linearly, and the free tier ends the moment you gain traction.
The second cost driver is the runtime itself. A full Node.js runtime per request is comparatively heavy next to a small compiled server that does less work per request.
What the benchmark actually measured
In a peer-reviewed study (IT IS Proceedings 2023, page 124), gr8s served the same workload as Next.js SSR with about 5x fewer servers. Memory under load was 82.54 MB for gr8s against 411.91 MB for Next.js, and overall energy use was roughly 9.8x lower.
Fewer servers and less energy per request is what turns into a lower bill. It is a structural difference, not a discount.
What this means for a typical content site
For a content or marketing site doing around 100,000 visits a month, a usage-based setup can run from tens to a few hundred dollars a month once you leave the free tier. A self-hosted gr8s site runs on one modest VPS, and the managed plan is a flat 48 EUR a year.
The honest caveat: if you depend on platform-specific features, migrating is real work. Run the numbers for your own traffic before you commit.
Try it
The free plan is enough to benchmark a real build. Export your SPA, run the CLI, and compare your own hosting cost and page scores.