Zabbix migration from mysql to postgresql + timescaledb

[peperodrigudez]

Hello,

We have quite a big zabbix installation working with mysql and we were planning to move to postgresql with timescaledb.

We are worried about these points and would like to have an opinion about them and if you could confirm them

• By using postgresql with timescaledb, you lose flexibility — you can no longer define different retention periods (history and trends) for each metric.
• With Timescale, all items would have the same retention period (for example, 7 days of history and 180 days of trends).

Pros and cons of using timescaledb with Zabbix

• Advantages: better performance, automatic maintenance, and less risk of someone setting excessively long retention periods.
• Disadvantages: less control and customization per metric.

Is that true?

Thanks

[tim.mooney]

less risk of someone setting excessively long retention periods.

You don't say what version of Zabbix you are using, but Zabbix has long supported the ability to enforce a global retention period that would override any per-item setting. It's extremely likely your version already supports the global retention setting.

Regarding switching from mysql to postgresql+timescaledb, my recommendation is that you make that decision based upon database expertise within your organization. If you have staff that are strong with MySQL but not very familiar with PostgreSQL, then you're probably better off staying with MySQL. If you have staff that are just as experienced with PostgreSQL or even more experienced with it, then by all means switch.

Switching an existing environment and preserving your data is no small task. If you have staff that are experienced enough to do an ETL (export/transform/load), you should be fine running either database backend.

If I were in your situation, I think my first step would be to write a script that connects to the API and reports any items that have a history period longer than what you want. You could run it periodically and then just adjust the errant items to use the max history that you want. That should be a lot easier than an ETL, even if your database staff are wizards.

[peperodrigudez]

We are using Zabbix 7.0

Could you please reply to these concerns?

We are worried about these points and would like to have an opinion about them and if you could confirm them

• By using postgresql with timescaledb, you lose flexibility — you can no longer define different retention periods (history and trends) for each metric.
• With Timescale, all items would have the same retention period (for example, 7 days of history and 180 days of trends).

[cyber]

It is not PG with TS that brings that restriction of periods. As was already mentioned, Zabbix has for a long time already options to define global overrides for periods. These do not restrict you to define other values in item config, those are just not considered.. and it works the same way with mysql...



How often do you actually use different periods? And what is reasoning behind those... Just that someone decided that they define longer periods? Or they actually need it?
Timescale adds a lot to housekeeping speed and also allows compressing data, which reduces the DB size a lot.. That can help you to keep longer history..