Zabbix 8.0 is a release candidate: inventory before the LTS

Zabbix 8.0 is at release candidate and planned as the next LTS. A probe to record the server, database and frontend state the upgrade depends on.

By the Maborak engineering team · 2026-10-29 · 3 min read

Zabbix 8.0 is in release candidate and planned as the next long-term support release. The upgrade is not only a package change: the server, the database schema and the frontend must agree on a version, and a mismatch produces a frontend that loads but cannot read the data.

Checked 29 October 2026. 8.0.0rc3 release notes are dated 29 October 2026. The roadmap places the 8.0 LTS in the fourth quarter of 2026; treat the date as a plan, not a commitment.

Background

Zabbix ships standard releases roughly every six months and an LTS roughly every eighteen months. 7.4 is supported until 8.0 LTS arrives, which makes the 8.0 cycle the point where a 7.x estate plans its move. The release candidate is for testing; the LTS is the production target.

Mechanics

Three components carry a version: zabbix_server, the frontend (PHP), and the database schema. The schema version lives in the dbversion table. Starting a server against an older schema triggers an automatic upgrade on first start; that upgrade is the part that needs a backup and a maintenance window, because it rewrites tables and can be slow on a large history store.

The frontend and server must match. A new frontend against an old server, or the reverse, is a common half-finished upgrade.

Impact

A failed schema upgrade can leave the database unusable without the backup. Housekeeping and history tables are the largest, so the upgrade time scales with them, not with the number of hosts. A release candidate in production also puts you ahead of the fixes that land between RC and LTS.

Probe

zabbix_server -V
zabbix_proxy -V 2>/dev/null
zabbix_agentd -V 2>/dev/null

# PostgreSQL
psql -U zabbix -d zabbix -c 'SELECT * FROM dbversion;'
# MySQL/MariaDB
mysql -u zabbix -p zabbix -e 'SELECT * FROM dbversion;'

php -v

Record the output before touching anything. The dbversion row is the exact schema state the new server will upgrade from.

Size the rewrite:

SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

On MySQL, SELECT table_name, data_length+index_length FROM information_schema.tables WHERE table_schema='zabbix' ORDER BY 2 DESC LIMIT 10;.

Mitigation

Back up the database and the frontend configuration. A schema upgrade without a tested restore is not a plan.
Test the RC against a restored copy, not against production. Note the upgrade duration on the real history volume.
Upgrade server and frontend together, and update proxies after the server. Mixed versions during a rollout should be brief and intentional.
Keep the old packages until the new server has run a full housekeeping cycle.

Verification

zabbix_server -V
psql -U zabbix -d zabbix -c 'SELECT * FROM dbversion;'

Then confirm the frontend login, one host’s latest data, an active check and a trigger event. A matching version string does not prove that history queries and housekeeping still work on the upgraded schema.

Sources

Zabbix roadmap (checked 29 October 2026).
Zabbix release notes (8.0.0rc3, 29 October 2026).
Zabbix 8.0 upgrade notes.

Topics: observability, infrastructure

Back to all articles