Zabbix Dissection (Part Two): The Database Battle – Zabbix’s Relational Architecture vs. TSDB in Modern Monitoring

Before entering the discussion, it is necessary to emphasize that the goal of this series of articles is not to question the value or capability of the prominent IT infrastructure monitoring tools. Many of these solutions have been used in various organizations for years and play an important role in monitoring and managing IT environments. What is examined in this series of articles is more of an analytical look at some limitations and challenges that can become problematic for organizations. Therefore, if you intend to purchase Zabbix software, we suggest that before making a decision, you also study the series of articles on dissecting Zabbix.

In monitoring, everything depends on data — high volume, high velocity, and the constant need for real-time analysis. The critical question is whether Zabbix’s storage infrastructure can keep pace with this flood of time-series data.

While Zabbix is powerful in many respects, it is still built on an architecture designed years ago: storing monitoring data in relational databases. This choice made sense at the time, but today it has become one of the platform’s fundamental limitations. Relational databases were built for transactional workloads, not for the relentless stream of time-series data generated every second from hundreds or thousands of services. This structural gap means that at scale, the heaviest load falls not on Zabbix itself, but on its underlying database.

The result?

Slowness, latency, scalability constraints, and bottlenecks that undermine the performance of the entire system.

This article examines this Achilles’ heel of Zabbix’s architecture and explains why relying on relational databases is no longer sufficient for the demands of modern monitoring.

The Database Challenge in Zabbix

One of the major architectural challenges in Zabbix lies in how it stores monitoring data. Nearly all monitoring data is kept in relational databases such as MySQL or PostgreSQL. While this approach was reasonable during Zabbix’s early design, the rapid growth of infrastructure and the explosion in monitoring data volume have turned it into a significant constraint.

Monitoring data differs fundamentally from typical database workloads. It consists of time-series data — continuously generated, high-frequency, and extremely high-volume. A single server or service can emit multiple metrics every few seconds; at scale, this results in millions of records per day.

Key issues include:

Continuous write operations

Every new metric in Zabbix triggers an INSERT operation. With many monitored systems, this becomes hundreds of thousands of writes in short time windows, placing heavy pressure on the database.

Rapid table growth

Data is stored in tables such as history, which quickly grow to millions or billions of rows. This expansion bloats indexes and slows down queries.

Heavy reporting and graphing

Generating graphs and historical reports requires querying these large tables. As data volume increases, query execution times rise, sometimes causing noticeable system slowdowns.

Housekeeping overhead

To manage database size, Zabbix runs a housekeeping process to delete old data. In large environments, even this maintenance task can impose significant load.

As a result, in many large-scale deployments, the database becomes the primary performance bottleneck. This is why modern monitoring architectures increasingly adopt specialized time-series databases (TSDBs) optimized for handling massive volumes of temporal data.

Why Time-Series Data Requires Specialized Databases

To understand Zabbix’s architectural limitations, it is essential to recognize that monitoring data is inherently time-series in nature — continuously produced, regular, and high-volume. This characteristic makes relational storage inefficient and prone to becoming a performance chokepoint over time.

Traditional relational databases were designed for structured transactional data, not for continuous streams of time-based information. TSDBs were specifically created to address the weaknesses relational systems exhibit with this workload:

Time-based storage organization

TSDBs structure data around timestamps and data series, enabling them to remain performant even at very high volumes.

Optimized for temporal pattern queries

Monitoring typically involves analyzing trends over time. TSDBs execute time-based queries with minimal overhead, without complex operations on massive tables.

Built for bursty ingestion

Monitoring data flows are not perfectly uniform; spikes are common. TSDBs are engineered to handle these bursts efficiently.

Native retention policies

TSDBs include built-in mechanisms to define how long data should be kept and how it should be downsampled or deleted. In contrast, Zabbix relies on the heavyweight Housekeeping process running on the relational database.

In short, time-series data is not merely a data type — it demands a dedicated architectural approach.

Zabbix’s Dependence on Housekeeping and Its Impact on System Stability

Because Zabbix uses relational databases for time-series data, a significant portion of system efficiency depends on a process that is inherently ill-suited for the workload: Housekeeping. This process deletes old records, but in real-world enterprise environments it often becomes one of the most resource-intensive and sensitive operations.

Why Housekeeping becomes a bottleneck

At high data volumes — which are normal for Zabbix — deleting individual records in a relational database is extremely expensive. Housekeeping must constantly purge millions of rows, acquiring locks that interfere with normal operations such as inserting new metrics. Consequently, housekeeping shifts from a periodic maintenance task to a near-constant background burden.

Consequences at scale

When housekeeping falls behind, effects cascade through the system: database performance degrades, data ingestion lags, internal queues fill up, and eventually some metrics are lost entirely. In these conditions, the monitoring tool itself becomes unreliable, undermining confidence in the very data needed for decision-making.

TSDBs solve this fundamentally by dropping entire time-based segments instead of deleting individual records. Deletion becomes a lightweight, fast operation that does not disrupt core system functions. This architectural difference turns housekeeping in Zabbix into an operational risk, while in modern time-series platforms it is a simple, non-disruptive routine.

Ultimately, the issue boils down to a mismatch between data type and storage engine — a mismatch that makes Zabbix increasingly fragile at enterprise scale and imposes hidden operational costs on IT teams.

Impact of Instability on Data Accuracy and Monitoring Trustworthiness

The limitations of Zabbix become most apparent at high scale, where the system should demonstrate maximum stability. Instead, the older architecture leads to slowdowns, processing delays, and occasional data loss. The outcome is incomplete graphs, gaps in historical data, and alerts that arrive late or not at all.

When the source of truth for infrastructure health becomes inconsistent, operations teams lose the ability to perform rapid root-cause analysis or make confident decisions. A monitoring platform that should be a pillar of reliability gradually becomes a source of uncertainty.

Why Zabbix’s Architecture Hits Limits at Scale

As infrastructure grows in size and complexity, monitoring tools must handle high data volumes, intricate dependencies, and concurrent events without degradation. In practice, Zabbix struggles in these scenarios due to heavy reliance on manual tuning, persistent database pressure, and challenges in managing large volumes of alerts. Operations teams end up spending significant time maintaining the monitoring system itself rather than focusing on the services it is meant to protect.

This often results in increased operational complexity, delayed problem detection, and reduced visibility into service health. Many organizations eventually conclude that the root cause lies not in configuration or scale, but in the fundamental architecture of the tool. This practical experience drives teams toward modern solutions designed from the ground up for large-scale, high-velocity environments.

Platforms such as Moein were built with exactly this modern approach — reducing operational complexity, delivering unified service visibility, and enabling sustainable management of high data volumes without heavy manual configuration and time-consuming processes. As a result, teams can shift their focus back to their core mission: ensuring service reliability and performance.

Series of Articles on Dissecting Zabbix