Datadog vs Zabbix - Five Differences to Look at When Considering a Migration
Where is the value in moving to Datadog for a team that gets by with Zabbix, and conversely, for which organizations is it more rational to stay on Zabbix? This article sorts it out using only public information. It lines up Zabbix's free license + support contract against Datadog's per-host price, and checks what you can carry over and what you leave behind in a migration through five differences.
Zabbix and Datadog Differ in Generation and Scope
Zabbix is open-source monitoring software that you install and use on your own servers. Datadog is a SaaS; once you install the Agent or connect a cloud account, data is gathered on the Datadog side. Even though both are "monitoring tools", they differ in the generation they were born in and in scope, so a comparison that ranks them by feature list does not connect.
| Aspect | Zabbix | Datadog |
|---|---|---|
| Delivery form | Self-installed software (AGPLv3 from 7.0 onward) | SaaS. Data is stored on the Datadog side |
| Cost model | No license fee. Paid offering is a support contract (four tiers, annual contract) with unlimited monitored hosts | Per-host price (monthly Infrastructure Monitoring Pro / Enterprise) + per-product SKUs |
| Strong areas | Availability / performance monitoring of servers and network devices. Data kept in your own DB | Correlation of cloud / container metrics with logs / traces. More than 1,000 integrations |
| What operations require | Building and maintaining the Zabbix server, database, and web interface | Agent distribution and tag conventions. No platform maintenance needed |
To state the conclusion first: for an organization whose monitored targets are fixed on-premises servers and devices, whose staff know Zabbix thoroughly, and which cannot send data outside the company, staying on Zabbix is the more rational choice. Conversely, for an organization whose monitored targets scale up and down across cloud and containers, whose incident investigations do not end with metrics but need to descend into logs and traces, and which cannot spare people to maintain the monitoring platform, Datadog's per-host price makes economic sense as the price of outsourcing platform operations. This article checks this fork through cost structure, operational requirements, and the five differences you actually face in a migration. This article explains how billing works. For current unit prices and plans, refer to each vendor's official pricing page.
Cost Structure - Free License + Support Contract, or Per-Host Price
Zabbix's costs are easily misunderstood, so let us pin down exactly what the official pages say. As of September 2026, the license is "published under AGPLv3 from version 7.0 onward", and up to 6.4 it is GPLv2. The official site writes that "if you use it in a commercial context, please support development by purchasing technical support", but there is no license cost for use itself (Source: Zabbix License). The paid subscriptions are support contracts, not rights to use the software, and the official page explains: "no license fees, no tax on growth; price is determined by coverage, access, and commitment; unlimited hosts / devices / applications, users / metrics / alerts". The support contracts come in four tiers, Silver / Gold / Platinum / Enterprise, with the price determined by coverage hours (8x5 or 24x7), response time, the number of covered servers, and support for distributed monitoring; the top two tiers are by individual quote. A 5-year security fix guarantee is included in all contracts (as of September 2026, Source: Zabbix Subscriptions). Datadog's Infrastructure Monitoring Pro and Enterprise are monthly per-host prices, proportional to host count (billing unit as of August 2026, Source: Datadog Pricing). For the actual unit prices, check each vendor's official pricing page.
| Line item | Zabbix | Datadog |
|---|---|---|
| Software use | No license fee (AGPLv3) | Included in the per-host price |
| Variable that moves the cost | Support contract tier (coverage, response time, commitment). Host count is unlimited and does not affect the cost | Monitored host count x per-host price. Grows in proportion to host count |
| When the monitored host count grows tenfold | The support contract cost does not change | Host billing grows tenfold |
| Operations included | You build and maintain the server / DB / retention yourself | Includes 15 months of storage and platform availability |
| Billing beyond host count | None (price varies by support coverage) | Per-product SKUs such as log ingestion / custom metric overage / APM |
Looking only at the "when the monitored host count grows tenfold" row of the table, the contest appears settled, but Zabbix's absence of a license fee carries the server and labor costs covered in the next section. The correct formula for the comparison is "Datadog's host count x unit price" versus "Zabbix's server cost + operations staff hours x hourly rate + a support contract if needed", and the harder it is for an organization to read the right-hand side of this formula, the more the clarity of the left-hand side matters. The stacking structure of the pricing is covered in How to Decode the Pricing Structure.
With Self-Hosting, You End Up Owning the Server and the Database Yourself
Zabbix's official documentation describes the architecture as a central server that agents report to, a database that stores all configuration and collected data, a web interface that usually runs on the same machine as the server, optional proxies for load distribution, and agents placed on monitored targets (two kinds from 4.4 onward: Zabbix agent and Zabbix agent 2) (as of September 2026, Source: Zabbix overview). The requirements page is even more concrete. It states that the disk needed depends on the number of monitored hosts and parameters, that you should plan for at least several gigabytes if you keep a long history, that the more physical memory you have the faster the database runs, and that depending on the number of monitored parameters and the database engine, considerable CPU may also be required. In addition, it strongly recommends running the database on a separate server in large configurations, and lists the supported databases as MySQL / Percona / MariaDB / PostgreSQL (including the TimescaleDB extension) (Source: Zabbix Requirements).
- Building the Zabbix server and managing versions - including updates to the OS, PHP, and web server
- Database capacity planning and tuning - the longer the history retention, the more partitioning and compression design becomes a job
- Availability of the server itself - detection and recovery procedures when the monitoring server goes down
- Proxy placement - maintaining collection paths per site and VLAN
- Backup - protecting the DB that holds configuration and history
These five items are, conversely, also Zabbix's strengths. Because the data is in your own DB, you decide both the retention period and the storage location yourself, and you can meet the requirements of an organization that cannot send data outside the company. Datadog takes on all five items in exchange for the data being held on the Datadog side, with retention determined by plan (15 months for metrics on Infrastructure Monitoring Pro / Enterprise, as of August 2026, Source: Datadog Pricing, cited above). Whether you buy "the freedom of owning it yourself" or "the ease of not owning it" is the choice in this section.
Zabbix Wins on Fixed Costs, On-Premises Device Monitoring, and Fully Self-Hosted Retention
There are three points where Zabbix wins structurally. All are the kind of difference that Datadog cannot close by adding features. First is cost fixity. Because the support contract price does not depend on the number of monitored hosts and is explicitly stated as "unlimited hosts / devices / applications" (as of September 2026, Source: Zabbix Subscriptions), Zabbix-side costs do not increase even if monitored targets grow from 100 to 1,000. For an organization that wants to fix its budget at the start of the fiscal year, this property is easier to handle than SaaS usage-based billing. Second is on-premises device monitoring. Zabbix has a built-in mechanism for monitoring via SNMP "devices such as printers, network switches, routers, and UPS units where SNMP is enabled and installing an OS and agent is not practical", and SNMP checks are performed over UDP (Source: Zabbix SNMP agent). Datadog also has a product for monitoring network devices, but on the pricing page it is offered as a separate SKU billed per device (Network Device Monitoring) (as of September 2026, Source: Datadog Pricing). At a site with dozens of switches and UPS units, Zabbix's "everything together on one server" is simpler. Third is fully self-hosted retention. Because all configuration and collected data are stored in your own database (Source: Zabbix overview), even an organization with rules prohibiting monitoring data from leaving the company can meet its requirements. If these three points are in effect as constraints on your organization, the decision to stay on Zabbix is correct, and there is no reason to rush a migration.
Datadog Pays Off Under Three Conditions: Changing Targets, Correlated Investigation, and Alert Fatigue
Datadog's strengths, too, are shown through design rather than adjectives. First, environments where monitored targets scale up and down. Installing the Datadog Agent gives you more than 50 host metrics by default, and tags attached to the Agent are carried on every metric / log / trace (as of September 2026, Source: Why should I install the Datadog Agent on my cloud instances?). In Zabbix, monitoring begins only after you create a host and link a template (Source: Zabbix Templates), whereas in Datadog, EC2 instances added by autoscaling are detected by the AWS integration and containers are followed by the Agent. In environments where a host's lifetime is a few hours, this "visible without registration" design becomes the operational difference. Next, environments where investigation does not end with metrics. Zabbix is designed around items (numeric time series) and triggers (Source: Zabbix overview). In Datadog, metrics, logs, and traces are tied together by the same tags, so you can descend on one screen to "the logs when CPU spiked" and "the slow requests at that moment". Finally, countermeasures against alert fatigue. Datadog's Monitors can be designed to aggregate alert targets by tag into a single monitor, and in the comparison table on the pricing page, Enterprise includes anomaly detection and forecast monitoring (as of September 2026, Source: Datadog Pricing). Zabbix triggers also have suppression through dependencies (Source: Zabbix Trigger dependencies), but the basic unit of aggregation is the host and the template. If 2 or more of the 3 conditions apply to your environment, there is a prospect of recovering the per-host price as the cost of "shortened investigation time and outsourced platform operations".
Five Differences to Look at in a Migration - What You Carry Over, Leave Behind, and Rebuild
What the people who actually do the work face once a migration is decided is not a difference in features but a difference in design philosophy. We split it into five and check for each "can it be carried over as is".
| Difference | Zabbix's approach | Datadog's approach | Can it be carried over? |
|---|---|---|---|
| 1. Metric naming | Defined as items (keys) per host | Combination of metric name + tags. The host is one of the tags | Rebuild a name correspondence table |
| 2. Templates vs tags | Link templates directly to each host to distribute items and triggers | Narrow targets dynamically with tags (env / service / team) | Translate the template classification into tag conventions |
| 3. Triggers vs monitors | Per-host triggers. Suppressed via dependencies | Monitors aggregated by tag. Notify as a single item | Reuse thresholds, redesign aggregation granularity |
| 4. Retention | In your own DB, for a period you decide | Determined by plan (Infrastructure Monitoring: 15 months for metrics) | Do not assume history can be brought in |
| 5. Permissions and where data lives | Self-contained within your own server | On the SaaS side. SSO from Pro upward | Confirm first whether off-site storage is permitted |
Zabbix's official documentation defines a template as "a set of entities that can be conveniently applied to multiple hosts", and explains that linking it to a host adds items and triggers, and that changes on the template side propagate to all linked hosts (Source: Zabbix Templates, cited above). What plays the same role in Datadog is Tags: "hosts running Apache" is determined not by a template link but by a matching service tag. In other words, the essence of the migration is the work of "translating the list of templates into tag conventions", and if this is done carelessly, you will be unable to filter either dashboards or monitors on the Datadog side. Conversely, items 1 and 3 proceed mechanically. Threshold numbers can be reused, and the correspondence table between item keys and metric names only needs to be built once. Item 4 requires a clean decision: do not assume that years of history accumulated in Zabbix will be brought into Datadog, and if needed, keep Zabbix as read-only. Item 5 is a matter of rules, not technology, so confirm it first. If it is a no-go here, the migration itself does not hold.
Steps for Running in Parallel, and What to Check Before Deciding to Migrate
In practice, you do not switch all at once; you take a parallel running period in which Datadog is placed alongside while Zabbix remains. The officially provided path is Datadog's Zabbix integration, and the official documentation as of September 2026 lists two uses: "monitor Zabbix with the Datadog Agent" and "send Zabbix alerts to Datadog and view them as events in the event stream". This is a community integration not included in the Agent package, and with Agent 7.21 or later you install it with the following command (Source: Zabbix Integration).
datadog-agent integration install -t datadog-zabbix==<INTEGRATION_VERSION>Alert forwarding works by creating a Webhook Media Type on the Zabbix side and passing the Datadog API key and template variables such as {EVENT.NAME} and {EVENT.NSEVERITY} as parameters, and the prerequisite that the Zabbix server's time zone be set to UTC is explicitly stated (same source). What you gain from this parallel run is the experience of seeing on one screen "what was happening in the Datadog-side metrics and logs at the time a Zabbix trigger fired". Continue this for 1 to 2 months, and the design of items 2 (tag conventions) and 3 (aggregation granularity) among the five differences in the previous section will solidify on real data.
- 1. Confirm the rules - can monitoring data be placed in an external SaaS? If not, continuing with Zabbix is settled
- 2. Target churn - is a host's lifetime a day or less, or years? If years, Zabbix's registration model is not a problem
- 3. Depth of investigation - does it end with metrics, or descend into logs and traces?
- 4. Platform operation hours - how many hours per month go into maintaining the Zabbix server and DB? Multiply by the hourly rate and set it beside Datadog's host count x per-host price
- 5. Device ratio - if SNMP devices make up the majority of monitored targets, running both with Zabbix kept for device monitoring is realistic
If you stop at 1, there is no need to agonize; if 2 to 4 lean toward Datadog, start with a parallel run; and if 5 is large, settling into a division of "servers and cloud in Datadog, devices in Zabbix" is the realistic landing point. The steps after deciding to adopt are summarized in the Adoption Checklist, and the comparison with the Grafana family in Datadog vs Grafana.
References
- Zabbix License (move to AGPLv3 and licenses of older versions)
- Zabbix Subscriptions (support contract prices and coverage)
- Zabbix overview (official documentation / architecture)
- Zabbix Requirements (official documentation / requirements)
- Zabbix SNMP agent (official documentation)
- Zabbix Templates and template groups (official documentation)
- Zabbix Trigger dependencies (official documentation)
- Zabbix Integration (Datadog Docs)
- Why should I install the Datadog Agent on my cloud instances? (Datadog Docs)
- Datadog Pricing (official pricing page)