MySQL runs Zabbix perfectly well until the history tables get big. Then the questions start: why housekeeping never seems to finish, why a six-month graph takes twenty seconds, and where the disk went. PostgreSQL with TimescaleDB is the usual answer. This is what it actually buys you, what it costs, and how the migration hangs together - so you can decide before you book the downtime.
Nobody migrates a working database for fun. The reason to do this is that PostgreSQL can carry the TimescaleDB extension, and TimescaleDB changes how Zabbix stores time-series data:
DELETE that competes
with live inserts and becomes a matter of dropping whole chunks that have aged out.These are projections from the Zabbix Architecture Planner, at Standard monitoring depth with one year of retention and stable growth. "Uncompressed" is the raw volume of history and trend data; "with TimescaleDB" applies the planner's compression factor.
| Scale | Devices | NVPS | Uncompressed | With TimescaleDB | Saved |
|---|---|---|---|---|---|
| Small | 100 | 117 | 76 GB | 30 GB | 46 GB |
| Medium | 1,000 | 1,167 | 762 GB | 305 GB | 457 GB |
| Large | 5,000 | 5,833 | 3.7 TB | 1.5 TB | 2.2 TB |
| Enterprise | 20,000 | 23,333 | 14.9 TB | 6.0 TB | 8.9 TB |
Read the last column, not the percentage. The planner models compression as a fixed ratio, so the proportional saving comes out the same at every scale by construction - that is an assumption in the model, not a finding. What changes the decision is the absolute number: 46 GB is a rounding error you would happily ignore, 8.9 TB is a procurement conversation.
These are modelled figures, not measurements from a specific migration, and the uncompressed side ignores storage engine overhead such as InnoDB row and index costs - so a real MySQL database is likely somewhat larger than shown. Run your own numbers in the planner or the database size calculator.
The thing that surprises people is that this is two separate jobs, not one. The data and the schema travel by different routes.
The data moves with pgloader, which reads the MySQL database and writes into PostgreSQL.
The schema does not come from MySQL at all. It comes from the Zabbix source tarball matching the exact version you are running - table definitions, indexes, alter operations, and trigger functions are pulled out of the official schema file as separate pieces and applied around the data load. Tables first, then pgloader moves the rows, then indexes, alters and triggers go on top, followed by a vacuum.
This is why your exact version matters. Not "Zabbix 7" - the precise release you are running. The schema you rebuild has to match the binaries that will talk to it, so the first thing to establish is your running version, and the sources you download must be that same version.
Once the database is in place there are two more steps that are easy to overlook. Zabbix ships database-specific binaries, so the MySQL server and web packages come off and the PostgreSQL ones go on - this is a package swap, not a configuration change. And the frontend keeps its own credentials, so its configuration file is removed to make the first-time setup wizard run again and collect the PostgreSQL details.
TimescaleDB itself is a separate exercise afterwards. The migration lands you on plain PostgreSQL; enabling the extension, tuning it, and loading the TimescaleDB schema is a second pass. That is worth knowing because it means the two halves can be scheduled apart - you can move to PostgreSQL one weekend and turn on compression the next.
scram-sha-256 afterwards
and the password regenerated again. It is temporary by design - but it is a step
you have to remember to walk back.Every command, in order, on a live system - including the parts that go sideways and get corrected on camera, which is usually where the useful detail is:
The walkthrough follows the Initmax community wiki page on migrating Zabbix from MySQL to PostgreSQL, which is where the copy-pasteable commands live.
A lab migration and a production one are different animals - the difference is almost entirely in the downtime and the rollback plan. Tell me the size of your database and what your outage window looks like, and I will tell you how I would approach it.