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.

Where Zabbix and Datadog stand (compiled from each vendor's public information as of September 2026)
AspectZabbixDatadog
Delivery formSelf-installed software (AGPLv3 from 7.0 onward)SaaS. Data is stored on the Datadog side
Cost modelNo license fee. Paid offering is a support contract (four tiers, annual contract) with unlimited monitored hostsPer-host price (monthly Infrastructure Monitoring Pro / Enterprise) + per-product SKUs
Strong areasAvailability / performance monitoring of servers and network devices. Data kept in your own DBCorrelation of cloud / container metrics with logs / traces. More than 1,000 integrations
What operations requireBuilding and maintaining the Zabbix server, database, and web interfaceAgent distribution and tag conventions. No platform maintenance needed
Source: Zabbix License / Zabbix Subscriptions (as of September 2026) / Datadog Pricing (as of August 2026)

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.

Cost structure correspondence table (Zabbix = as of September 2026 / Datadog = as of August 2026)
Line itemZabbixDatadog
Software useNo license fee (AGPLv3)Included in the per-host price
Variable that moves the costSupport contract tier (coverage, response time, commitment). Host count is unlimited and does not affect the costMonitored host count x per-host price. Grows in proportion to host count
When the monitored host count grows tenfoldThe support contract cost does not changeHost billing grows tenfold
Operations includedYou build and maintain the server / DB / retention yourselfIncludes 15 months of storage and platform availability
Billing beyond host countNone (price varies by support coverage)Per-product SKUs such as log ingestion / custom metric overage / APM
Sources for the billing structure: Zabbix Subscriptions / Datadog Pricing, cited above. Zabbix-side server costs and labor costs are not included

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
Work that recurs continuously in self-hosted Zabbix operation (compiled from the official architecture and requirements descriptions)

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".

Five differences when moving from Zabbix to Datadog (compiled from official documentation as of September 2026)
DifferenceZabbix's approachDatadog's approachCan it be carried over?
1. Metric namingDefined as items (keys) per hostCombination of metric name + tags. The host is one of the tagsRebuild a name correspondence table
2. Templates vs tagsLink templates directly to each host to distribute items and triggersNarrow targets dynamically with tags (env / service / team)Translate the template classification into tag conventions
3. Triggers vs monitorsPer-host triggers. Suppressed via dependenciesMonitors aggregated by tag. Notify as a single itemReuse thresholds, redesign aggregation granularity
4. RetentionIn your own DB, for a period you decideDetermined by plan (Infrastructure Monitoring: 15 months for metrics)Do not assume history can be brought in
5. Permissions and where data livesSelf-contained within your own serverOn the SaaS side. SSO from Pro upwardConfirm first whether off-site storage is permitted
Basis: Zabbix Templates / Zabbix overview / Datadog Pricing

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
Five items to check before deciding to migrate (checking them in order leads to a faster decision)

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

Share