Server Sizing Calculator

Pick a workload, describe its shape, and get a spec you can actually order - with the reasoning shown.

Workload

nginx, Apache or Caddy serving static files, proxying to an app tier, or terminating TLS for an API.

Recommended for Web server

Minimal

Runs correctly today. No room to spare.

CPU
--
RAM
--
Disk
--
Comfortable

Survives growth, a deploy and a bad day. Start here.

CPU
--
RAM
--
Disk
--
Storage class

--

Operating system

--

Where these numbers came from

Sized for the comfortable tier. If you buy the minimal box, recompute the memory-proportional settings from that machine's RAM rather than scaling these by the difference: some of them have a floor the smaller tier cannot go under.

Tuning notes

    The calculation runs entirely in your browser: the numbers you type are never sent to us. If analytics are enabled we record which workload was sized and the rounded result, never your inputs.

    The three ways server sizing goes wrong

    Sizing to the average instead of the peak

    A server sized to mean utilisation is a server that falls over on the busiest day of the year. The number that matters is the p99, and the gap between it and the average is bigger than most people assume - a service averaging 30% CPU can spend several minutes a day above 90%.

    Forgetting the moments when both copies are resident

    A rolling deploy runs the old and the new worker set at the same time. A Redis BGSAVE forks and copy-on-write duplicates every page written during the save. A Postgres VACUUM FULL needs room for a second copy of the table. Each of these roughly doubles a resource for a few minutes, and each is a well-known way to take down a host that had been fine for months.

    Sizing the machine instead of the bottleneck

    Adding cores to a single-threaded Redis does nothing. Adding RAM to a database whose queries are unindexed buys a little time and hides the cause. Before buying a bigger machine, find out which of CPU, memory, disk or network is actually saturated - it is frequently none of them, and the real limit is a connection pool or a file descriptor ceiling.

    Rules of thumb this calculator uses

    Workload The number that drives it Rule
    Web server Requests per second ~4,000 rps/core static, ~1,500 proxying, ~800 terminating TLS
    PostgreSQL Working set 15-30% of the database in RAM for OLTP, 35-65% for analytics, plus ~10 MB per connection
    MySQL / MariaDB InnoDB buffer pool Pool holds the hot set and is ~65% of RAM, so size the machine backwards from it
    Redis / Valkey Dataset plus fork headroom 1.25-1.45x for overhead and fragmentation, plus up to 0.7x again if persistence is on
    Application server Workers x resident size Double it for the deploy window, when both worker sets are live
    Container host Sum of container limits Plus ~1.5 GB for the OS and daemon, and disk for image layers nobody pruned
    Kubernetes node Pod requests Allocatable is ~85% of capacity, plus 1-2 GB of DaemonSets charged per node

    These are starting points, not guarantees. They are the numbers a sysadmin would reach for before measuring, and measuring is what should replace them.

    How to check what your servers actually use

    Every recommendation on this page is an estimate standing in for a measurement. If the server already exists, four commands beat any calculator:

    vmstat 1 30

    Thirty one-second samples. Watch the r column (processes waiting on CPU) and si/so (swap activity). Any sustained swapping means you are short on RAM, whatever the free memory figure says.

    free -h

    Read the available column, not free. Page cache counts as used but is reclaimable, so a healthy Linux server always looks nearly full.

    iostat -x 1

    The %util and await columns tell you whether the disk is the bottleneck. High await with low IOPS usually means the wrong storage class rather than too little of it.

    ss -s

    Socket counts. Useful when a server that looks idle is refusing connections, which is a ceiling somewhere else and not a sizing problem at all.

    The catch is that a snapshot taken now tells you nothing about last Tuesday's peak, and peak is what you size for. That is the case for continuous collection: the Fivenines agent records CPU, memory, disk and network every few seconds and keeps the history, so the next sizing decision starts from a graph instead of a guess.

    Explore next

    Related Resources

    Disk Space Calculator

    Plan storage from log volume, retention and growth rate.

    Explore ->

    Load Average Interpreter

    Check whether the cores you have are already saturated.

    Explore ->

    Linux Server Monitoring

    Measure what your servers really use before you size the next one.

    Explore ->

    Database Monitoring

    Buffer pool hit rate, connections and query load for Postgres, MySQL and Redis.

    Explore ->
    Compare alternatives

    See how Fivenines compares to other tools

    Fivenines vs Netdata Fivenines vs Datadog

    Read our guide to the best infrastructure monitoring tools in 2026.

    FAQ

    How much RAM does PostgreSQL need? +
    Enough to keep the working set in memory, which is rarely the whole database. For an OLTP workload budget 15-30% of the database size plus about 8-12 MB per connection; for analytical queries budget 35-65%, because a scan touches far more of the data. Then set shared_buffers to roughly 25% of the machine's RAM and effective_cache_size to roughly 75%. The second one allocates nothing - it tells the planner how much OS page cache it can assume, and leaving it at the default is a common reason the planner avoids an index it should be using.
    How many CPU cores does a web server need? +
    It depends far more on what the server does with a request than on how many requests arrive. A core serves roughly 4,000 requests/sec of static files, roughly 1,500 as a reverse proxy, and roughly 800 when it is also terminating TLS, because the handshake is the expensive part. Divide your peak requests per second by the right figure, then double it for headroom: a web tier sized exactly to peak has nothing left for a traffic spike, a slow upstream, or a certificate renewal.
    Why does Redis need more RAM than my dataset? +
    Two reasons, and the second one is what actually kills hosts. Keys, pointers and allocator fragmentation cost 25-45% on top of the values themselves. And if persistence is on, BGSAVE and AOF rewrite both fork the process: copy-on-write means every page the parent writes while the child is saving gets duplicated, so a write-heavy instance can approach double its resident size during a save. Sizing to the dataset and then enabling persistence is the most common way a Redis box gets OOM-killed.
    How do I size a Kubernetes node? +
    Start from pod requests, then add back what the scheduler never sees. kube-reserved, system-reserved and the eviction threshold take roughly 15% of capacity before any pod is placed, and the kubelet, container runtime, CNI and your DaemonSets (log shipper, metrics agent, CSI plugin) take 1-2 GB on top - charged per node, so smaller nodes pay it more often. Also check the pod count: kubelet's default --max-pods is 110, and your CNI's per-node address range usually caps you before the kubelet does.
    What is the difference between the minimal and the comfortable tier? +
    Minimal is what the workload needs to run correctly today with no room to spare. Comfortable adds headroom for the things sizing exercises forget: traffic growth, a rolling deploy where the old and new worker sets are both resident, a failed node whose traffic lands on its neighbours, and the memory a long-running process accumulates that a fresh one does not. If the workload takes real traffic, size to comfortable. Minimal is for a staging box or a cost floor you are arguing about.
    Are these recommendations exact? +
    No, and no sizing calculator's are. These are rules of thumb applied to the numbers you entered, and the tool shows the intermediate figures it derived so you can check its reasoning rather than take the answer on faith. Real sizing comes from measuring the workload under real load. That is the case for monitoring: the Fivenines agent installs in two minutes and tells you what your servers actually use, so the next sizing decision starts from data instead of an estimate.

    Stop sizing from guesses

    Fivenines records what your servers actually use, so the next sizing decision starts from data.

    Start monitoring with fivenines.io

    14-day trial. No credit card required.