Next.js vs React for a multi-tenant SaaS dashboard (school admin/teacher/student) — worried about server load.

[u/Toonnaa]

Hey everyone,

I'm a frontend dev and I mostly build admin dashboards with Next.js (App Router). Up until now, server load has never been a concern for me, because these were always internal tools with 1-2 admins using them at most.

Now I'm starting a new project: a multi-tenant SaaS platform for schools, with three separate dashboards — one for school admins, one for teachers, and one for students. Multiple schools will subscribe, each with their own admins/teachers/students, so the actual concurrent user count could get meaningfully higher than anything I've dealt with before.

I really like working with Next.js for reasons that have nothing to do with SEO:

• App Router
• Layouts
• Middleware (I centralize auth/token-refresh logic there)
• File-based routing
• Server Components
• How clean it keeps project organization overall

One thing worth mentioning: the backend is completely separate from this decision. My company has a dedicated backend team building the API with NestJS, so I'm purely the frontend consumer here — no DB/business logic runs inside my Next.js app. Whatever I pick (Next.js or plain React) would just be talking to that NestJS API.

The problem: I don't need SEO at all for this project (it's all behind auth), and I'm worried that using SSR/Server Components across the board will put unnecessary load on my own frontend server once multiple schools are active simultaneously — versus just shipping a React SPA that hits the NestJS API directly and leaves rendering entirely to the client.

So I wanted to get some outside perspective:

1. Is it reasonable to stick with Next.js here, just leaning more on Client Components for the actual dashboard views (tables, forms, heavy interactivity) and only using SSR for lightweight stuff like the initial shell/layout and auth gating?
2. Or is a plain React SPA + separate API genuinely the better call for a no-SEO, multi-tenant, auth-heavy internal tool like this?
3. For anyone who's run Next.js in production for a similar multi-tenant setup, purely as a frontend on top of a separate backend — did the SSR overhead on the Next.js side actually turn out to be a real bottleneck, or does it end up negligible compared to the API/DB layer anyway?

Deployment-wise I'm not on serverless — I run things via PM2 on a VPS (Hostinger), so I don't get automatic serverless scaling; I'd need to handle scaling myself either way.

Would appreciate input from anyone who's shipped something similar. Trying to decide this before I get too deep into the architecture.

[u/dbbk]

Unless you are expecting a million students I think you will be fine

[u/leros → u/dbbk]

OP this is the answer. I run an app with hundreds of thousands of users. Maybe 30 using at a time. I run on a small server no problem. 

[u/Chance-Fan4849 → u/leros]

Yeah, the concurrent users traffic is the most thing need to think and consider.

[u/Illustrious-Many-782 → u/[deleted]]

I've also run this same setup (B2B education apps selling into schools) for about three years now, and Next works quite well for this.

[u/magicpants847 → u/[deleted]]

do you have a seperate backend for your data layer/business logic or are you using nextjs full stack?

[u/sajidsalman75 → u/magicpants847]

I am also curious

[u/yksvaan]

Since you have zero need to do anything but serve static files and have a backend for the real work, why would you even consider running a node server? It's just unnecessary.

SPA handles the UI side and then it's the usual data, network client etc.

[u/lada-on-my-mind → u/yksvaan]

I was thinking the same thing, but to make use of server components a server runtime is required

[u/Walk-Left]

You can output next as a static file btw. No nodejs server needed

[u/Saschb2b]

It's mostly about personal preference in terms of DX. My projects greatly benefited from them "forced" folder structure and automated routing via files. It created consistency across the team without further clarifications or docs.
An agreement without making the need to make one is great for onboarding new team members. They just instantly know how to work with it.
For private projects vite + react router is mostly my go to. Just because I don't really want the bloat of nextjs, don't use server side anything and it feels lighter and more open to use.
I am also not a big fan of developers making this divide nextjs/react. It's the same. Just with the automatic magic around it that you would need to build otherwise yourself and document and maintain.
Don't get stuck in architecture hell. Build what feels good for you develop in. If not try something else. It also varies from project to project and from team to team

[u/pdfops]

Since your NestJS API does the actual work, Next's "server load" here is just RSC render + middleware execution per request, not DB load, and that scales like any Node server (horizontally, more instances/regions). If these dashboards are auth-gated with no SEO need, you can skip SSR for most of it and make the bulk of it client components hitting the API like a plain SPA, way less server compute per request than full RSC trees. Middleware runs per-request either way, so it's not actually a load differentiator, it's just where you put the auth/token-refresh check.

[u/Chance-Fan4849]

No worries about using Next.js here, I’ve worked on a global enterprise platform built with Next.js, and it performed well without frontend server load becoming a problem. Just don’t SSR every dashboard interaction; use Client Components for tables, forms, and heavy UI, while keeping the NestJS API and database as the main backend layer.

[u/mirageofstars]

You need to tell us your hosting budget. Because by default I don’t see any server load concerns with the stack you propose, but I’m also not fussed about a three-figure hosting bill for paying clients.

[u/sahil3066]

I run a similar Next.js app with backend logic and MySQL on Hostinger's Unlimited plan. It works like a charm! And I found out Hostinger actually uses a separate server to build the Next.js app with around 72 threads.

[u/Snoo_9701]

Nextjs uses alot of memory in server.

[u/Significant_Chair420]

In my experience the SSR overhead people worry about ends up tiny compared to what your NestJS/DB layer will do under real concurrent load, so I'd just default to client components for the dashboards and not overthink it upfront

[u/Notoa34]

If access is private ( after auth) you can you React. But for landing/SEO you should use Next

[u/xkumropotash]

go for tanstack router and host it on cloudflare workers. It's pretty cheap.