A Node.js application needs far less memory than most sizing guides imply, but it needs it in a specific shape: a fixed per-process floor of roughly 50–80 MB for the runtime, plus memory proportional to concurrent requests, plus a heap limit you set deliberately. Get those three numbers right and a 1 GB server will handle a surprising amount of traffic. Get them wrong and a 4 GB server will still die under a load spike.
This article gives measured numbers for each layer, works through three realistic workloads, and shows the cheapest plan tier that comfortably fits each. Figures assume Node 20 or 22 on Debian or Ubuntu, with no database on the same box unless stated.
The memory baseline of a Node process
Start by measuring rather than guessing. On a running server:
# resident memory of the node process
ps -o rss= -p $(pgrep -f "node .*server.js") | awk '{print $1/1024 " MB"}'
# heap usage from inside the app
node -e "console.log((process.memoryUsage().heapUsed/1048576).toFixed(1)+' MB used')"Typical measured values for a minimal Express or Fastify service with a handful of dependencies:
| Component | Idle RSS | Notes |
|---|---|---|
| Node runtime (empty process) | 38–45 MB | V8 baseline, independent of your code |
| Express + 10–20 small deps | 65–85 MB | Grows with dependency count, not usage |
| Fastify equivalent | 55–70 MB | Lower per-route overhead |
| ORM + database pool (5 conns) | +15–30 MB | Pool buffers dominate |
| Per concurrent request in flight | 0.3–2 MB | JSON payloads, buffered uploads push higher |
| OS + SSH + logging | 180–260 MB | Before anything Node runs |
Per-request memory is the number people underestimate. A request that streams a 4 MB upload into a buffer costs 4 MB until the buffer is released; ten concurrent uploads cost 40 MB. A JSON API returning 2 KB responses costs almost nothing per request by comparison. This is why cargo-culting a “256 MB per process” rule from a tutorial produces servers that swap at the worst possible moment.
Three workloads, three RAM tiers
1. A small API for a side project
Fastify service, PostgreSQL client, 20–80 requests per minute at peak, no file uploads. Measured RSS settles at 75–95 MB. Add 220 MB of OS and you are at roughly 320 MB. A 1 GB plan leaves 600–700 MB free for the page cache, which is where the performance benefit actually comes from. This workload runs comfortably on the cheapest 1 GB tier available.
2. A production API with a colocated database
Express service at 400–600 requests per minute plus PostgreSQL on the same host. Node needs 150–220 MB, PostgreSQL needs 350–450 MB with a modest shared_buffers of 128–192 MB, and the OS needs 250 MB. Total: 800–900 MB. Add headroom for a deploy overlapping two processes, and the real requirement is 1.5–2 GB. On 1 GB this stack will still run, but every backup or migration will push it into swap.
3. A file-processing or image-resizing service
The same Node service, but each request holds a decoded image or CSV in memory. Ten concurrent 6 MP image jobs at 24 MB each is 240 MB of transient allocation, on top of a 120 MB baseline. This workload needs 2–4 GB or an architectural change: move processing to a queue with a concurrency limit of two or three. Limiting concurrency is almost always cheaper than buying memory.
Setting the heap limit to match the plan
By default V8 lets the old-space heap grow to about half of system memory, and it is slow to return memory to the OS. On a 1 GB container that default is dangerous: the process can push the whole node into swap before it garbage-collects. Set an explicit cap that leaves room for everything else:
# 1 GB plan, Node only
NODE_OPTIONS="--max-old-space-size=512"
# 2 GB plan, Node + Postgres
NODE_OPTIONS="--max-old-space-size=384"The rule of thumb: max-old-space-size at no more than 45% of total RAM, minus what your database consumes. If the process hits the cap and crashes, that is a signal to investigate a leak or add capacity — not to raise the cap and let the OOM killer decide instead.
Process management changes the maths
- One process, clustered workers: each worker duplicates the heap. Four workers on a 2 GB box gives you four 300 MB caps to balance, and a leak in one worker is masked until all four grow. Prefer two workers on small plans.
- PM2 in cluster mode: adds roughly 40–60 MB for the master process and its logs. Worth it for restart handling; budget the memory explicitly.
- Docker: the container runtime adds about 10–20 MB per container but the daemon itself is 100–130 MB. Docker on a 512 MB plan leaves almost nothing for the app.
- Build tooling:
npm installandnext buildpeak far above runtime memory — 800 MB to 2 GB for a mid-size Next.js app. Build in CI, or temporarily enable swap, rather than sizing the production plan for the build.
Cheapest plan that fits, by workload
| Workload | Runtime RSS | Total need | Minimum sensible plan | Typical monthly cost |
|---|---|---|---|---|
| Static API, low traffic | 80 MB | ~320 MB | 512 MB – 1 GB | $2–$5 |
| API + Postgres | 200 MB | ~900 MB | 2 GB | $6–$10 |
| API + Redis + Postgres | 280 MB | ~1.4 GB | 2–4 GB | $10–$16 |
| Image processing, 10 concurrent | 400 MB+ | ~2.5 GB | 4 GB | $14–$24 |
| Next.js SSR, moderate traffic | 250–400 MB | ~1 GB | 2 GB | $6–$12 |
Note that the jump from a low-traffic API to an API with a database roughly triples the price. Splitting the database onto a managed service is rarely cheaper at this scale, but splitting Node and Postgres across two 1 GB servers at $4 each is often the same price as one 2 GB plan and gives you independent restarts. Our budget VPS plans by memory tier lay out the options at each size.
How to verify the plan is genuinely big enough
Deploy, run a load test, and watch two numbers: free -m available memory and vmstat 1 5 swap in/out. If swap usage climbs steadily during the test, the plan is too small regardless of what the heap limit says. If available memory stays above 200 MB under peak, you have bought correctly — and if it stays above 500 MB, run the same test on the next tier down before renewing. A 30-minute test at hourly billing costs cents and routinely saves $3–$6 per month, which is the entire margin on a budget node. For related sizing methods, see the value-focused hosting guides on memory and CPU budgeting.
