Zabbix hardware requirements: sizing the server, the database and the proxies

"How much hardware do I need for Zabbix?" is the question every team asks before they start, and the official documentation answers it with a single table. Here is that table in full, because it is short enough to reproduce - and that is most of the problem.

Source: Zabbix documentation, Installation → Requirements, version 7.4 at the time of writing. A footnote defines the unit as 1 metric = 1 item + 1 trigger + 1 graph.

What that table cannot tell you

Nothing in it is wrong. It is just not a plan, and four things are missing that you need before you can buy anything.

• It does not say what the box is. One CPU and memory pair per band, with no split between the Zabbix server, the database, the frontend and any proxies. Those have genuinely different appetites - the server wants cores, the database wants memory and write throughput.
• Nobody counts their estate in metrics. You know you have 400 Linux servers, 60 switches and 25 database hosts. Converting that to a metric count means knowing how many items each template brings, which is the actual work.
• There is no disk sizing in it. Storage is discussed further down the same page, in prose, as a worked example - and it is the number that decides your budget.
• Retention is not a variable anywhere. Yet keeping 180 days of history instead of 30 multiplies your database by six.

There is one genuinely useful thing to know about that table, which is not written on it: those figures behave like the server and the database added together. Run the numbers through the tiering below and Very large lands on exactly 32 cores and 96 GB once you sum both machines, and Large matches on cores. So read the official row as a budget for the pair, not a spec for one host.

The rest of this page fills in the four gaps: how to get from a list of devices you want to monitor to a number of values per second, and from there to cores, memory and terabytes of database disk.

Step 1: count your Zabbix items

Everything downstream is driven by how many things you collect, so start there. A "host" in Zabbix is not a useful planning unit, because one host can carry ten items or five hundred depending on what it is and which templates you attach. What works is a rough item count per device, chosen by how deep you intend to monitor:

These are planning averages across a mixed estate, not per-device truth - a 48-port switch with interface discovery running blows past 200 items on its own, while an appliance with a single ICMP check sits at three. They are good enough to size with, and far better than guessing at a band in the official table.

Step 2: convert items to NVPS (new values per second)

New values per second is the number that everything else in Zabbix sizing keys off. It is simply how many items you have divided by how often you poll them:

NVPS = total items / average check interval in seconds

At a 60 second average interval - a reasonable default, and the one the official docs use in their own example - 5,000 devices monitored at Standard depth comes out as:

5,000 devices x 70 items   = 350,000 items
350,000 items / 60 seconds =   5,833 NVPS

The average matters more than it looks. Move a large template group from 60 seconds to 30 and you have doubled that half of your estate. If you already run Zabbix, you do not have to estimate at all: the Zabbix server health dashboard graphs your real NVPS, and that measured figure beats any calculation here.

Step 3: Zabbix server requirements - CPU and memory

Zabbix server requirements follow directly from NVPS, because it is NVPS that puts you in a tier. These are the figures the planner uses, per machine, assuming the database is PostgreSQL with TimescaleDB:

The database always gets more memory than the server and never less CPU. That is not arbitrary: the server's job is to poll, preprocess and evaluate triggers, which is CPU-bound and comfortably parallel, while the database is absorbing every one of those values as a write and then answering dashboard queries against them. Memory is what keeps the working set off disk. Proxies sit at 4 cores and 8 GB almost regardless of scale, because in their default hybrid mode most of the work happens in RAM and very little touches their disk.

Step 4: Zabbix storage requirements and database size

Zabbix storage requirements are the part the official table omits entirely, and the part with a budget attached. Two tables dominate. History holds every raw value you collect. Trends holds a one hour min/max/avg/count roll-up per item, and that one hour period is fixed - you cannot tune it.

history bytes = NVPS x 86,400 x history_days x 90 bytes
trends  bytes = NVPS x     24 x trends_days  x 128 bytes

The 90 bytes per numeric value is the figure from the Zabbix documentation itself. The 128 bytes per trend row is deliberately more conservative than the docs' ~90, because a trend row carries four aggregates rather than one value. Text and log items are wilder - budget around 500 bytes a value for those, and keep an eye on any log item you leave running.

Then two adjustments. TimescaleDB's native compression takes roughly 60% off the stored size, so multiply by 0.40. And you never provision a disk to exactly the size of the data on it, so add 1.5x headroom for indexes, WAL, vacuum churn and the day you change your mind about retention.

Worked example: 5,000 devices, Standard depth, one year of look-back

Look at the two raw lines again, because the ratio is the single most useful thing on this page. History is 99.8% of that database and trends are 0.2%. A history row lands every 60 seconds; a trend row lands once an hour. Sixty times fewer rows, and they are the ones you keep for years.

The retention lever, and the one everyone pulls by mistake

Because of that ratio, "how far back do you want to look?" and "how much disk do you need?" are almost independent questions - as long as you understand which retention you are changing. Same 5,000 device estate, four different answers:

Going from one year of look-back to two costs about 6 GB. Going from 30 days of history to 90 costs you a terabyte and a half. Long-term reporting is nearly free; high-resolution recent data is what you are actually paying for.

Zabbix architecture: which shape do you need?

Hardware totals are only half of a plan. The other half is how many machines those totals are spread across, and that follows from scale, geography and how much downtime you can take. Four shapes cover almost everything:

Zabbix proxy requirements

Zabbix proxy requirements are modest, and you deploy one per remote location. A proxy collects locally and forwards in batches, which means a link that drops for twenty minutes gives you a gap of nothing rather than a wall of false alarms, and it moves polling load off the central server. Their hardware ask is modest - 4 cores, 8 GB, 20 GB of disk - but the RAM matters more than the disk, because a proxy in the default hybrid mode does most of its buffering in memory. Size the disk for how long you want it to survive a WAN outage without losing data.

High availability, and the half people forget

Zabbix has native server high availability built in since 6.0, and it is a few lines of configuration. That covers the server process. It does not cover your database, and a database outage stops monitoring exactly as dead as a server outage does. An HA pair on the server with a single database underneath it has simply moved the single point of failure somewhere less obvious. If you are building for failover, budget for a replicated standby database at the same spec as the primary - which, at these sizes, is the single biggest line item in the plan.

Before you buy anything

Every number here is a planning estimate, and the honest thing to say about all of them is that your estate will not match the averages. Three things sharpen the estimate at very little cost:

• Pilot 20 devices of each type with the templates you actually intend to use, then read the real item count off Zabbix and scale it. This converts the biggest guess on the page into a measurement.
• Watch your NVPS on the built-in server health dashboard once anything is running. If it is 40% above your estimate, everything downstream is 40% out too.
• Provision the database disk so it can grow. LVM, a cloud volume that resizes, or a filesystem you can extend online. Retention policies change, estates grow, and the alternative is a migration.

And size for where you will be, not where you are. An estate that doubles in two years wants the database disk it will need then, because that is the component that is painful to change later. Cores and memory can wait.

Watch the walkthrough

Nine minutes on why the documentation's table cannot answer this question on its own, and a run through the planner end to end on a 5,000 device example - the questions it asks, the architecture it lands on, and how to read the result.

Related tools