Real-world cost of Server Components (App Router) vs. CSR at scale?

[developer-choi]

Hello everyone,

First, I just want to say thank you to the Next.js team and the community. We've been using the App Router at my company and are very impressed with its capabilities.

I'm writing because we had an internal debate today, and I would love to get some real-world perspectives from this community.

The Debate: Performance vs. Cost

The argument was made at my company that server-side rendering (and by extension, Server Components) is computationally expensive. The concern is that if we build most of our pages as Server Components (as recommended), our server costs will become too high.

The suggestion was that we should:

1. Only use Server Components for a few, critical, performance-sensitive pages.
2. Default to a traditional Client-Side Rendering (CSR) approach (e.g., using tanstack query) for the majority of our application to save on server costs.

My Perspective

My counter-argument, which is based on the official documentation, is that Server Components are the recommended default. The docs encourage server-first data fetching and rendering, with client components used as needed for interactivity.

My personal philosophy is that no page is 'unimportant' when it comes to performance—a faster load time is always better for the user experience. I believe the advancements in the App Router, like Streaming and especially Partial Prerendering (PPR), are technologically far superior to traditional CSR for achieving this.

The Missing Piece: Concrete Cost Data

While I can find many articles (including from major tech companies in Korea) that praise the performance benefits of SSR, I cannot find concrete data on the cost.

It's obviously true that rendering and fetching on the server will increase server load compared to serving static files. But the key questions are:

• By how much?
• Is the cost increase so significant that a B2C site with substantial traffic would find it financially unsustainable to build all its pages with a server-first approach?

What I'm Looking For

I'm hoping to hear from other teams running Next.js at scale. I'm essentially looking for answers that fall into one of two camps:

1. "Yes, the cost is a major issue."
   (e.g., "We are a company of size X with Y daily active users, and we found the server costs of the App Router were too high, so we had to strategically move most of our app back to CSR.")

   or

2. "No, the cost is not a deal-breaker."
   (e.g., "The cost increase was manageable and not a significant problem. The performance benefits for our users far outweighed the infrastructure cost. You should build according to the App Router's philosophy.")

My gut feeling is that since Next.js is trusted by startups and massive enterprises alike, if the cost was a prohibitive issue, I would have heard about it by now. But I would love to replace my assumptions with real data and anecdotes from the community.

Thanks in advance for sharing your experiences!

Follow-up clarification:

Just to clarify, the pages we are debating are private pages that require authentication (e.g., personalized user dashboards). These must be rendered dynamically for every user on every request, as they cannot be cached.

If we were talking about public pages, this cost debate wouldn't be relevant because of force-cache and static regeneration. My question is specifically about the cost of fully dynamic, uncached, server-first rendering versus a traditional CSR + API approach.

[tyagi-anurag]

@developer-choi
Your colleague's fear of high server costs likely comes from old-school SSR (like getServerSideProps) which was computationally expensive because it ran on every request

The App Router's philosophy is the opposite its default is aggressive and automatic caching most Server Components only run once at build time or on the first request and the results are served statically from the edge this is often cheaper than a CSR approach which requires a separate API call from every single client to fetch data

You only incur server costs when you explicitly opt out of caching for truly dynamic data (e.g., a user's dashboard) but in a CSR model you'd still pay for that exact same compute via an API route you'd just be making the user wait longer for it

So to answer your question "No, the cost is not a deal-breaker"

The App Router is built on this "static-first" caching model which is highly cost-effective at scale the real bottleneck is almost always the database not the rendering and the performance benefits for the user far outweigh the manageable costs

[developer-choi]

@tyagi-anurag

I've just edited/updated my post to include this clarification, as I had missed this crucial context. I'd really appreciate any additional answers you can provide!

Follow-up clarification:
Just to clarify, the pages we are debating are private pages that require authentication (e.g., personalized user dashboards). These must be rendered dynamically for every user on every request, as they cannot be cached.
If we were talking about public pages, this cost debate wouldn't be relevant because of force-cache and static regeneration. My question is specifically about the cost of fully dynamic, uncached, server-first rendering versus a traditional CSR + API approach.

[developer-choi]

I agree with your analysis.

I think The cost of server-side rendering is primarily the computation of running React code on the server to create the resulting RSC Payload.

I strongly believe this is far less expensive than the cost of querying the database from the backend API.

Whether we use SSR or CSR, we have to call the backend API in the end. It feels absurd to debate where the rendering happens while ignoring the database cost, which is clearly the bigger bottleneck.

As far as I know, personalized data can't be stored in the App Router's Data Cache. In that case, it seems like using Tanstack Query with a long staleTime could result in fewer backend API calls compared to SSR.

However, if the cost of API calls was that critical, websites from the past that used technologies like JSP (before CSR or SSR even existed) would have found it impossible to operate due to the high costs.

They generated HTML on every single request, complete with database queries.

[tyagi-anurag]

I agree with your analysis.

I think The cost of server-side rendering is primarily the computation of running React code on the server to create the resulting RSC Payload.

I strongly believe this is far less expensive than the cost of querying the database from the backend API.

Whether we use SSR or CSR, we have to call the backend API in the end. It feels absurd to debate where the rendering happens while ignoring the database cost, which is clearly the bigger bottleneck.

As far as I know, personalized data can't be stored in the App Router's Data Cache. In that case, it seems like using Tanstack Query with a long staleTime could result in fewer backend API calls compared to SSR.

However, if the cost of API calls was that critical, websites from the past that used technologies like JSP (before CSR or SSR even existed) would have found it impossible to operate due to the high costs.

They generated HTML on every single request, complete with database queries.

youre thinking about it in the right way once you clarify that these pages are fully dynamic uncached peruser pages the debate boils down to this

csr vs ssr doesnt change the true cost driver the database does

whether you render on the server rsc ssr or the client csr api

the db query still runs

the backend function still executes

the same business logic still needs to happen

the only difference is where the react tree is turned into bytes

and rendering react on the server is not the expensive operation people imagine

1 react rsc rendering is extremely cheap

react server components dont hydrate dont ship js and dont do clientside reconciliation
the output is a lightweight rsc payload far cheaper than legacy ssr

2 csr does not save compute

csr just moves the cost from server rendering to extra api calls

and at scale

1 million users making api calls
costs more than

1 server rendering react plus 1 db call

every csr page extra network roundtrip extra backend request extra coldstart penalties

3 big companies confirm this

teams at vercel notion hulu tiki and even cloudflare workers have shared the same conclusion

the bottleneck is your data access layer not reacts server rendering

4 if ssr cost was unsustainable old web stacks would have collapsed

php rails jsp laravel django spring all did full html rendering per request

if rendering html was too expensive the entire pre spa internet couldnt have existed

tldr

for private dynamic pages

ssr rsc cost ≈ csr api cost

db access dominates

server components still remove js bundle cost improve ttfb and simplify code

realworld teams rarely switch back to csr because of cost the tradeoff usually goes the other way

so no the cost of serverfirst pages is not a dealbreaker at all and very often ends up cheaper than csr once you factor in api traffic and hydration overhead

[developer-choi]

@tyagi-anurag
Thank you so much for sharing your insights. Have a great weekend.

[tyagi-anurag]

@tyagi-anurag Thank you so much for sharing your insights. Have a great weekend.

@developer-choi pleasure is mine Sir.

[lewiii254]

In my experience, the cost difference between RSC/SSR vs CSR is usually overstated. For fully dynamic, authenticated pages, both models pay for:

• a database query
• some backend compute
• serialization of the result

Whether the computation produces HTML/RSC payload on the server or JSON for the client to hydrate doesn’t materially change infra cost. The true bottleneck at scale is almost always database I/O, not React rendering.

We’ve benchmarked this internally: rendering React on the server added only a small % of overhead compared to the DB + business logic layer. Even high-traffic dashboards stayed well within normal CPU budgets. The only time SSR becomes noticeably expensive is if the page’s server logic is doing heavy CPU-bound work unrelated to the DB — which is uncommon in typical B2C apps.

So for your question:
No, the cost of dynamic Server Components hasn’t been a deal-breaker.
The user-experience wins (no waterfalls, streaming, less JS shipped) were far more impactful than the small increase in server compute.

CSR isn’t “free” either — it just shifts the work to users’ devices and adds more round-trips to APIs. At scale, these API calls easily match or exceed the cost of server-side rendering lightweight RSC payloads.

[developer-choi]

@lewiii254
Thank you so much for your thorough and thoughtful response.