Most PostgreSQL servers we see on customer VPS instances are either twice the size they need to be or one bad query away from the OOM killer. Neither is a mystery — both come from sizing the machine before understanding what the database actually holds. This post is the sizing conversation we have over tickets, written down: how to work out which shape you need, what to set once you are on it, and what it costs per month in each of our locations.
Start with three numbers, not the plan list
Before you look at any hosting page, get these three figures from your current database or a realistic estimate of it:
- Total size on disk.
SELECT pg_size_pretty(pg_database_size('yourdb'));Include indexes — they are usually 30–60% on top of the table data. - The working set. The slice of that data your queries actually touch in a normal day. For most web applications it is the recent rows, not the archive: often 10–20% of the total.
- Peak concurrent connections. Each backend process costs memory. If your framework opens 50 connections and holds them, that is 50 processes, and
work_memis charged per sort node, not per connection.
The sizing rule that follows from those three: you want the working set to fit in RAM, with headroom for connections and the OS. Not the whole database — the working set. A 60 GB database with a 6 GB working set is comfortable on a machine with 8 GB of memory and miserable on one with 2 GB, and both cost less than the 32 GB box you were about to buy.
Mapping working sets to our shapes
Our six shapes and what each one realistically carries as a PostgreSQL host. Prices are per month in Bucharest, which is our base price; Frankfurt and Vienna are the most expensive locations, so both columns are shown to bracket what you will pay:
| Shape | RAM | vCPU | Disk | Realistic PostgreSQL role | Bucharest | Frankfurt / Vienna |
|---|---|---|---|---|---|---|
| VPS I KVM | 2 GB | 1 | 20 GB | Development, CI fixtures, a single low-traffic app under a few GB | €4.00 | €5.50 |
| VPS II KVM | 4 GB | 2 | 40 GB | Small production app, working set up to ~2 GB | €6.00 | €9.00 |
| VPS III KVM | 8 GB | 2 | 60 GB | The common sweet spot: working set up to ~5 GB, 20–50 connections | €10.00 | €16.00 |
| VPS IV KVM | 16 GB | 4 | 80 GB | Reporting alongside OLTP, heavier sorts, working set ~10 GB | €16.00 | €26.00 |
| VPS V KVM | 24 GB | 6 | 100 GB | Multi-tenant SaaS database, parallel query, working set ~16 GB | €30.00 | €44.00 |
| VPS VI KVM | 32 GB | 8 | 120 GB | Large working set, several parallel workers, analytics on a replica | €58.00 | €78.00 |
Two things about these machines matter specifically for databases. We do not put an IOPS ceiling on VPS plans, and we do not cap CPU as a percentage — the vCPU count is the limit, not a throttle underneath it. If your database is disk-bound at 3am during a vacuum, it is not because we are shaping you.
Disk: size for growth, not for today
PostgreSQL needs room for the data, the WAL, a vacuum's worth of churn and whatever you dump locally before shipping it off the box. A practical floor is 2.5× your current database size, and more if you keep base backups on the same machine (you should not).
If you outgrow the plan's disk, extra storage is sold in 50 GB increments at €4 per month each, up to three increments — so a VPS III can carry 60 GB of plan disk plus 150 GB of add-on storage. That is usually cheaper than jumping two shapes for capacity you do not need in RAM.
What to set once you are on the box
Defaults ship conservative because PostgreSQL does not know how big your server is. On a dedicated database VPS, four settings do most of the work:
shared_buffers— about 25% of RAM. 2 GB on an 8 GB machine. Going much higher rarely helps because the kernel page cache is also caching your data.effective_cache_size— about 60–75% of RAM. This one allocates nothing; it tells the planner how much cache to assume, which decides index scans versus sequential scans.work_mem— start at 16–32 MB, per sort. Charged per sort or hash node, multiplied by parallel workers. Ten concurrent reports with three sorts each at 64 MB is 1.9 GB of memory you did not budget for. Raise it per session for known-heavy queries instead of globally.maintenance_work_mem— 256 MB to 1 GB. MakesVACUUM, index builds and restores dramatically faster and is only used by one maintenance operation at a time.
Then set max_connections to what you actually need and put a pooler in front of the application. A connection pooler on the same VPS costs you nothing in hosting and saves more memory than any shape upgrade.
Prove the shape with an hourly box before you commit
This is the part people skip. You do not have to guess which shape is right — restore a real dump onto a real machine and watch it. Every shape in the table above is available on hourly billing, which makes the experiment cost less than lunch:
- A VPS III at €0.0139 per hour in Bucharest: about €0.06 for a four-hour restore-and-benchmark session.
- The same test on a VPS V at €0.0417 per hour: about €0.17.
- Run both, compare, destroy the one that lost. Billing stops when the machine is destroyed.
Restore your dump, run your slowest report, watch pg_stat_statements and the cache hit ratio, then decide. The ratio to look at is blks_hit / (blks_hit + blks_read) in pg_stat_database — if it is under about 95% on a warm database, your working set is not fitting in memory and the next shape up is the honest answer.
One practical note on hourly: an hourly service needs at least €5 of account credit before it can be created, and it is charged from that balance each hour. Stopping the virtual machine does not stop the meter — the machine is still allocated, still holding its RAM and disk. Destroy it when the test is over.
Where to put it
Put the database in the same location as the application servers that query it. Splitting them across countries adds the round trip between those two cities to every single query, and a chatty ORM that issues 200 queries per page request will feel all 200 of them. If the app is in Frankfurt, put the database in Frankfurt. Our five live locations are Bucharest, Warsaw, Amsterdam, Frankfurt and Vienna, and the location pricing post has what each one costs.
If your data must stay in the EU for contractual or GDPR reasons, all five are EU locations — including the cheapest one. That is not the case with every provider's cheap region.
Backups are your job, and they are not snapshots
Unmanaged means unmanaged: nobody at Noded is watching your pg_dump cron. A workable minimum on a single VPS:
pg_dump -Fcnightly to a directory that is not on the database volume, then copy it off the machine the same night.pg_basebackupweekly if you need point-in-time recovery, with WAL archiving to somewhere that is not this server.- A restore test once a month. A backup you have never restored is a hypothesis.
For the machine itself, you can capture your own image from the client panel — up to three images per account, billed at €0.06 per GB per month for what they occupy. That is a fine way to keep a known-good build of a database server, and a poor substitute for a logical dump of the data.
How Noded Can Help
If you already know your working set, pick the shape from the table and order it on the hourly VPS page. If you do not, order a VPS III on hourly billing, restore a real dump, and let the cache hit ratio tell you whether to move up or down — the whole experiment is a few cents. Running the database behind an application that is already on one of our machines? Keep them in the same location and you are done.
If you want a second opinion on sizing before you buy, open a ticket with your database size, working set and peak connection count. We will tell you the smallest shape that fits, including when that is smaller than what you were about to order.
FAQ
How much RAM does PostgreSQL need?
Enough for your working set plus the OS and connection overhead — not your whole database. A 60 GB database whose queries only touch recent data runs well in 8 GB. Check blks_hit versus blks_read in pg_stat_database: a warm cache hit ratio above about 95% means the memory is sufficient.
Can I run PostgreSQL on the €4 plan?
For development, CI and small side projects, yes — 2 GB of RAM and 20 GB of disk is a real PostgreSQL server. For production with paying users, start at the 8 GB shape unless you have measured that you need less.
Do you throttle disk I/O on VPS plans?
No. There is no per-plan IOPS or bandwidth ceiling on the disk, and no CPU percentage cap — the vCPU count is the limit.
Can I add disk without changing plan?
Yes. Extra storage comes in 50 GB increments at €4 per month, up to three increments per machine.
Which location should the database go in?
The same one as the application. All five of our locations are in the EU, so data residency is satisfied everywhere, and Bucharest is the cheapest if latency to your users is not the deciding factor.