For a typical production Node.js app with PostgreSQL on one VPS: 2 vCPU / 4 GB RAM / NVMe SSD.
That’s the baseline. The right size below or above it depends on where your project actually sits — a hobby project and a database serving real production traffic have very different floors, and the table below maps both.
Quick answer: a typical production Node.js + PostgreSQL app needs 2 vCPU / 4 GB RAM / NVMe SSD as a baseline — scale up or down using the tiers below.
| Tier | vCPU | RAM | Storage |
|---|---|---|---|
| Hobby / MVP | 1 vCPU | 1–2 GB | SSD |
| Production baseline Recommended | 2 vCPU | 4 GB | NVMe |
| Medium | 2–4 vCPU | 4–8 GB | NVMe |
| High | 4+ vCPU | 8–16 GB | NVMe |
Memory Budget Breakdown: Where the RAM Actually Goes
The 4 GB production baseline isn’t one number — it’s three components stacked on top of each other, and knowing the split is what lets you size up or down with confidence instead of guessing.
Quick answer: the 4 GB production baseline splits roughly into
OS overhead, Node.js’s V8 heap, and PostgreSQL’s shared_buffers — no single
component owns the full budget.
| Component | Typical footprint | Notes |
|---|---|---|
| OS baseline | ~500 MB – 1 GB | A minimal Ubuntu server plus SSH, systemd, and background services. |
| Node.js / V8 heap | ~1–2 GB(varies) | Modern Node.js (v20+) is container-aware and scales heap to roughly 50% of available
memory, capping around 2 GiB internally — it does not use a fixed default regardless of
system RAM. Set --max-old-space-size explicitly for predictable behavior on
a constrained VPS rather than relying on the automatic default. |
PostgreSQL shared_buffers | ~25% of total RAM | PostgreSQL’s own documentation recommends starting at 25% of system RAM, with diminishing returns above roughly 40% — on a 4 GB VPS, that’s about 1 GB. |
Add those up on a 4 GB VPS and you’re already close to the ceiling once the OS, Node’s heap, and Postgres’s shared buffers are all accounted for — which is exactly why the Production baseline tier assumes moderate, not heavy, concurrent load. Push past that with real traffic and the Medium or High tiers exist for a reason.
When to Split the Database onto Its Own VPS
The app and the database compete for the same CPU and RAM as long as they share one server. That’s fine at low-to-moderate traffic, but it stops being fine once either of these shows up:
- shared_buffers plus Node’s heap together leave under roughly 20% RAM headroom for the OS and connection overhead — the server is running structurally tight, not just busy.
- Database I/O and app request handling visibly contend under load — check with vmstat or iostat during peak traffic rather than guessing from CPU percentage alone.
- You’re past the Medium tier’s 4-8 GB range and still seeing contention — at that point, isolating Postgres onto its own VPS is usually cheaper than continuing to scale one combined server up.
Split on the actual symptom, not a fixed schedule — a low-traffic app can live comfortably on one combined VPS well past the Production baseline tier if it never shows these signs.
Mapping Each Tier to a Concrete Contabo Cloud VPS
Contabo’s smallest Cloud VPS plan already starts above the Hobby/MVP and Production baseline tiers — there’s no smaller product to map those two to, so both land on the same entry-level plan:
Quick answer: Contabo’s entry-level Cloud VPS 4 (4 vCPU / 8 GB) already covers both the Hobby/MVP and Production baseline tiers — you only need to move up for Medium or High workloads.
| Tier | Spec | Contabo product | Notes |
|---|---|---|---|
| Hobby / MVP | 1 vCPU / 1–2 GB | Cloud VPS 4(4 vCPU / 8 GB) | Exceeds this tier’s requirements — Contabo’s entry plan starts above hobby-level specs. |
| Production baseline Recommended start | 2 vCPU / 4 GB / NVMe | Cloud VPS 4(4 vCPU / 8 GB) | Same entry plan comfortably covers the production baseline with headroom to spare. |
| Medium | 2–4 vCPU / 4–8 GB | Cloud VPS 4–6 | Cloud VPS 6 adds headroom if the app and DB are both under real, sustained load. |
| High | 4+ vCPU / 8–16 GB | Cloud VPS 6–8 | Cloud VPS 8 is the point to consider splitting Postgres onto its own instance instead of scaling further. |
Plan names and specs current as of publication — verify current pricing and configurations on contabo.com.
FAQ: Node.js + PostgreSQL VPS Sizing
Modern Node.js (v20+) scales its heap to roughly half of available system or container memory, capping around 2 GiB internally by default — it isn’t a fixed amount regardless of RAM. On a constrained VPS, set –max-old-space-size explicitly rather than relying on the automatic default, so Node’s memory use stays predictable alongside PostgreSQL.
PostgreSQL’s own documentation recommends starting at 25% of total system RAM, with values above roughly 40% showing diminishing returns since the OS page cache handles the rest. On a 4 GB VPS running both Node.js and PostgreSQL, that’s about 1 GB for shared_buffers.
Move it once shared_buffers and Node’s heap together leave under about 20% RAM headroom, or once vmstat/iostat show real contention between database I/O and app request handling under load — not on a fixed traffic number. Below that point, one combined VPS is usually simpler and cheaper than managing two.
