Shared-Nothing vs One-Box Monolith Decision Tree

Shared-nothing architecture says every node holds its own state and no two nodes write the same disk. A one-box monolith says the opposite: one VPS, one Postgres, one Redis, one app, and you are done. Both are valid. The mistake is copying a fleet diagram onto a product that still fits in 8 GB, or staying on one box after Postgres CPU is the only graph that matters. This post is a decision tree you can walk once a quarter, not a slogan. Netbay has one datacenter — Lucknow DC01 — so "go multi-region" is not on the tree. Splitting roles across two VPS in the same site is.

Start at one box unless a test fails

Default to the one-box monolith with layers: nginx, app units, Postgres, Redis, all on loopback, all with their own memory caps. That default wins while all of these remain true.

• One team can SSH in and explain every unit.
• Peak CPU on the Xeon Platinum plan stays under about 70 percent for a week.
• Postgres disk growth is predictable and backups finish inside the window.
• A deploy cut (blue-green on two units) completes without swapping.
• Blast radius of a kernel panic is acceptable: minutes of downtime, not a contractual disaster.

If every line still holds, do not split. A second VPS adds a network hop, a second backup, a second fail point, and a second invoice. Shared-nothing is not a promotion. It is a response to a named bottleneck.

Split one concern, not the org chart

When a test fails, identify the hot resource and move only that.

App CPU or RAM: resize the plan before you add a node. Vertical scale on one hypervisor guest is still the cheapest split. If you are already at the top plan, add a second app VPS that talks to the existing Postgres over a private path you control, and keep nginx on the first box or in front. That is scale-out of the stateless layer. It is not shared-nothing yet, because both apps share the database.

Postgres CPU, I/O, or backup time: move the database to its own VPS with more RAM and High-Speed SSD, bind it to a private address, and point DATABASE_URL at it. The app VPS becomes closer to stateless. You now have two failure domains that do not share a kernel. That is the first split that usually pays.

Blast radius: if a kernel panic is no longer acceptable, split control plane and data plane onto two instances, or split the public site from the admin instance. Same city, same DNS family, different units of failure.

Shared-nothing enters when two app nodes must not share a disk and must not share a writable database for that data set. Sharded tenant databases, per-customer VPS, or a queue partition you cannot afford to lock globally. Most SaaS products never need that on day 30. Many never need it on day 300. Do not start there because a blog post used the phrase.

A checklist you can run, not a feeling

# once a quarter, on the production VPS
echo "== units =="
systemctl is-active nginx app postgresql redis-server
echo "== cpu mem disk =="
uptime
free -h
df -h / /var/lib/postgresql /var/lib/app
echo "== postgres =="
sudo -u postgres psql -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;"
echo "== listeners =="
ss -ltnp

# split_decision.py — print the next action, not a cluster
cpu = 62          # percent, week peak
backup_min = 18   # last backup duration
panic_ok = True   # contractual?
plan_top = False  # already largest VPS?

if cpu < 70 and backup_min < 30 and panic_ok:
    print("stay: one-box monolith with layers")
elif cpu >= 70 and not plan_top:
    print("resize the VPS plan, keep one box")
elif backup_min >= 30:
    print("move Postgres to a second Lucknow VPS")
elif not panic_ok:
    print("split control-plane VPS from data-plane VPS")
else:
    print("add a stateless app VPS in front of existing Postgres")

Refuse options that are not on the tree. A managed Kubernetes product is not something to wait for; it is not in the Netbay catalog. Object storage as a platform feature is not either; keep files on a disk you back up. Multi-region active-active is not a Netbay topology. When you do add a second instance, buy it the same way you bought the first: one REST purchase, one Lucknow DC01 VPS, one new role. Shared-nothing is a property of how those roles share disks, not a synonym for "more YAML."

Walk the tree on a Netbay Ubuntu 24.04 VPS, measure, and only then buy the second instance — netbayhosts.in.