Zabbix database sizing and TimescaleDB

The storage footprint of a Zabbix database is decided less by the number of hosts than by how long each kind of collected data is kept and how many items produce it. Zabbix stores two kinds of numeric data. History holds every raw value an item collects, at the collection interval you configured. Trends hold one aggregated record per item per hour, with the minimum, maximum, average and count of the values in that hour. Because trends carry far fewer rows, they can be kept for much longer than history without the same growth. Your retention settings therefore map to two different questions: how far back you can inspect the exact values during an incident, and how far back you can compare hourly behavior for capacity reporting. The two retention periods multiply with item count. Every additional item adds rows to history at its polling rate and adds rows to trends every hour, so a template applied to a few hundred hosts can grow the database far faster than the host count suggests. Before you set retention, export your item count by type and polling interval from a staging instance, then calculate expected rows per day for history and trends separately. Ask your implementation partner or your own DBA to show that calculation next to the disk budget. Items with short intervals, such as those on high-volume network interfaces, usually dominate growth, so they deserve a specific decision about interval or retention. The housekeeper is the Zabbix server process that deletes expired history and trends rows on a schedule. It runs in batches, and under heavy load it can fall behind: deletions queue up, the database keeps growing, and each run takes longer than the last. Watch the housekeeper in the server log and in the internal items that report its activity, and alert when a run takes longer than its interval or when the backlog of expired rows grows. The Zabbix requirements and the server configuration documentation describe the housekeeping settings, and you should confirm their current names and defaults for your target release before you change them. TimescaleDB changes the cost of deletion. With the extension, history and trends are stored in hypertables split into time-based chunks, and retention removes whole chunks that have expired instead of deleting millions of individual rows. This keeps deletion cheap and avoids long vacuum runs on large tables, but it only helps if chunk intervals match your data volume and if the extension version is supported for your PostgreSQL and Zabbix versions. Confirm the supported TimescaleDB range for your release in the Zabbix requirements page, and test chunk sizing on a copy of production data. Set retention from your own requirements, not from a default you found in documentation. Ask what period your incident reviews need at full resolution, and what period your capacity reports need in trends. Write those answers down, convert them into a storage estimate, and measure housekeeping duration and database size at go-live and again after the first full retention cycle. If housekeeping duration rises steadily, fix it before the backlog becomes an outage.

The sizing numbers in this guide are estimates until a load test confirms them against your own workload. Run the test with the sized item count and polling rate, not a smaller sample, because write latency and housekeeper behavior change sharply once the history tables grow. Build the test population from real templates and intervals, and add the trigger and event volume you expect during an incident, since alert bursts stress the database as much as steady polling does. Ask your team or partner to state in writing the item count, average refresh interval, number of proxies and retention settings used for the test, so the result can be compared with the sizing later.

During the load test, measure five things and record them with timestamps. Write latency on the history and trends tables shows whether the database keeps up with the value stream. Housekeeper duration shows whether deletion of expired history finishes within its cycle, which matters because a housekeeper that falls behind lets tables grow without bound. Frontend query time for common dashboards, latest data pages and history graphs shows whether operators will feel the load. Disk growth per day, measured on the database volume and not inferred from table sizes, gives the figure you will use for storage budgeting and retention decisions. For a TimescaleDB deployment, also record how chunk creation, compression and retention policies behave over the test period, because those jobs run separately from the Zabbix housekeeper and need their own evidence.

A restore test matters more than a backup job log. Restore the database from your most recent backup into a clean environment with the same PostgreSQL or MySQL-family engine version, the same extension version where TimescaleDB is used, and the same Zabbix server version. Start a Zabbix server against the restored database, confirm the frontend loads, and check that recent history, trends, hosts and users are present. Record the elapsed time from starting the restore to a working frontend, because that is the recovery time you can actually promise. If the restore fails or runs longer than the outage you can accept, change the backup method or the retention design before go-live, not during an incident.

Test failure behavior deliberately. Slow the database, for example by limiting its I/O or CPU in the test environment, and observe how the Zabbix server and proxies respond. Then fill the database volume in a controlled way and observe what stops first. The key question is whether monitoring data is queued by proxies during an outage or lost. Proxies buffer collected data locally for a period, but the buffer is finite, so confirm the buffer settings and the size of the proxy data volume against the outage duration you need to survive. Also confirm what the server does when it cannot write, whether it stops processing, and how the queue drains after recovery. Ask the team to document the alerts that should fire during these conditions, because a silent database fault is the most dangerous outcome.

Keep the results as acceptance evidence: the sized and tested item count, polling rate and proxy count, write latency and housekeeper duration under load, frontend query times, daily disk growth, the restore time and the observed proxy buffering behavior under database fault. Store them with the exact Zabbix, database and extension versions used. Repeat the full test after each upgrade, including minor releases, and after any change to retention, item count or hardware, because a result from an earlier version does not describe the new one. The Zabbix life cycle and release policy page lists the supported release lines, so confirm the version in use before you plan the repeat test.