Prometheus vs Datadog for Database Monitoring

Quick verdict

Prometheus describes itself as an open source systems monitoring and alerting toolkit, originally built at SoundCloud. It stores metrics as time series identified by a name and key-value labels, collects them through a pull model over HTTP, and is queried with PromQL. It joined the Cloud Native Computing Foundation in 2016 as its second hosted project, and all components are under the Apache 2 licence. The latest release on GitHub is 3.15.0 (September 2026). Prometheus does not connect to databases itself: an exporter queries the database and publishes metrics on an HTTP endpoint that Prometheus scrapes. Dashboards usually come from Grafana (AGPL-3.0-only) and notifications from Alertmanager.

Datadog is a commercial SaaS observability platform. Its Database Monitoring (DBM) product requires the Datadog Agent and documents support for self-hosted and managed Postgres, MySQL, MariaDB, Oracle, SQL Server, MongoDB, Amazon DocumentDB and ClickHouse. It collects query metrics for normalised queries, individual query samples and explain plans, alongside database-level metrics, and can be linked to Datadog APM traces. It is billed per database host.

Side by side

Key differences

Metrics toolkit versus database monitoring product

The main difference is scope. Prometheus is a general metrics system: it knows nothing about databases until you deploy an exporter, and what you see is whatever that exporter turns into numbers. The Prometheus-community postgres_exporter (Apache-2.0, CI-tested against PostgreSQL 13 to 18, default port 9187) publishes series such as pg_stat_database_xact_commit, pg_stat_database_deadlocks and replication and activity metrics; it recommends a monitoring user granted the pg_monitor role. The mysqld_exporter, maintained under the Prometheus organisation (Apache-2.0, MySQL 5.6 and later, MariaDB 10.3 and later, default port 9104), exposes mysql_up, mysql_global_status_* and optional Performance Schema collectors, and needs the PROCESS and REPLICATION CLIENT grants plus SELECT.

For SQL Server there is no exporter under the Prometheus organisation. The common route is sql_exporter, a permanent fork of the original database-agnostic SQL exporter, maintained by burningalchemist under the MIT licence (default port 9399). Its metrics are entirely defined by YAML collector files of SQL queries, and it supports SQL Server, MySQL, PostgreSQL, Oracle, ClickHouse, Snowflake and Vertica. Grafana's Alloy collector ships a prometheus.exporter.mssql component that embeds sql_exporter with a default set of SQL Server queries (connections, deadlocks, batch requests, page life expectancy, memory and I/O stalls).

Datadog DBM, by contrast, is built for databases: it collects query metrics for normalised queries, samples of individual executions and explain plans, and lets you filter by team, service, host or cluster. That is the layer most teams want when asking "which query got slower", and it is the layer a plain Prometheus setup mostly lacks.

Query-level detail

Both build on the database's own statistics. On PostgreSQL that means pg_stat_statements: Datadog documents it as required for its postgresql.queries.* metrics, and postgres_exporter has a stat_statements collector that is disabled by default and limited by default to the top 100 statements with query text cut to 120 characters. On MySQL, mysqld_exporter can read Performance Schema statement summaries. In Prometheus these become extra time series per statement, which raises label cardinality, so they are normally capped. Prometheus's own overview notes that it is not a good choice where you need every event recorded in full. Datadog stores query samples and explain plans as records rather than metric series, which suits drilling into a single slow execution.

What running it yourself involves

A Prometheus stack is several components you deploy, upgrade and secure: the Prometheus server, one exporter per database (or a multi-target exporter), Grafana, and Alertmanager. Prometheus's documentation states that local storage is not clustered or replicated and should be managed like any single-node database, and retention defaults to 15 days unless configured. Longer history or high availability usually means remote write to a separate long-term store. A minimal scrape configuration for one postgres_exporter looks like this (Prometheus YAML; scrape_interval defaults to 1m and metrics_path to /metrics):

# prometheus.yml (Prometheus configuration)
scrape_configs:
  - job_name: "postgres"
    scrape_interval: 30s
    static_configs:
      - targets: ["pg-exporter.internal:9187"]
        labels:
          env: "prod"

Both postgres_exporter and mysqld_exporter also support a multi-target pattern, in which one exporter serves several database servers through a /probe?target=... endpoint and Prometheus relabels each target into the request. A PromQL query for commits per second by database over five minutes, and a simple expression you could use in an alerting rule:

# PromQL: transactions committed per second, per database
sum by (datname) (rate(pg_stat_database_xact_commit[5m]))

# PromQL: MySQL exporter cannot reach its server (use in an alerting rule)
mysql_up == 0

Alerting rules are evaluated in Prometheus, which sends firing alerts to Alertmanager; Alertmanager handles silencing, inhibition, aggregation and delivery to email, on-call and chat systems. With Datadog, the Agent and the backend are run for you; on PostgreSQL you still create a monitoring user (Datadog also uses pg_monitor), enable pg_stat_statements and, for explain plans, create the documented function in each database. Datadog lists Agent 7.36.1 or later as the minimum for self-hosted Postgres DBM.

Linking database load to applications

Datadog documents a DBM and APM connection that injects trace identifiers into queries as SQL comments, in a "service" mode (service name only) or "full" mode (full trace context), for Postgres, MySQL, SQL Server, Oracle and MongoDB. You can then move from a slow trace span to the query sample and explain plan, or see which services drive a database's load. A Prometheus setup has no equivalent on its own; you would add a separate tracing system and correlate by time and labels. The difference between these two views is explained in Database Monitoring vs APM.

Combining them

The two are not mutually exclusive. The Datadog Agent can scrape Prometheus and OpenMetrics endpoints, so existing exporters can feed Datadog, but Datadog's documentation states that all metrics retrieved this way count as custom metrics, which are billed beyond each plan's allowance. Teams sometimes keep Prometheus for broad infrastructure metrics and add Datadog DBM only for the databases where query-level detail justifies the per-host cost.

Pricing and licensing

Prometheus, its exporters and Alertmanager are free open source software (Apache 2; sql_exporter is MIT). Grafana's open source edition is free under AGPL-3.0-only. The real costs are the servers and storage you run, any long-term storage behind remote write, and the time to build dashboards and rules and keep the stack upgraded. Managed Prometheus-compatible services also exist, with their own pricing.

Datadog Database Monitoring was listed on the vendor's pricing page in October 2026 at USD 70 per database host per month billed annually, or USD 84 per database host per month billed month-to-month or on demand. Infrastructure Monitoring is priced separately (Pro listed at USD 15 per host per month billed annually; Enterprise USD 23), and Datadog's free infrastructure tier covers up to 5 hosts with 1-day metric retention. Metrics scraped from Prometheus endpoints count as custom metrics. Check the current pricing page and your contract, as discounts and allotments vary.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You mainly run SQL Server and want a DBA-focused monitor with wait and blocking analysis: see Redgate Monitor vs SQL Sentry and Datadog vs SolarWinds DPA.
• You want a SaaS observability platform priced by data ingested rather than by host: see Datadog vs New Relic.
• You need occasional PostgreSQL query analysis rather than continuous monitoring: pg_stat_statements plus a log analyser may be enough; see pgAdmin vs pgBadger.
• You want an open source, database-focused stack with query analytics built in: compare the options in open source database monitoring tools.

Final recommendation

Frequently asked questions

Sources

• Prometheus documentation: Overview
• Prometheus documentation: Configuration (scrape_config)
• Prometheus documentation: Storage (retention, remote write)
• Prometheus documentation: Alerting overview (Alertmanager)
• Prometheus releases on GitHub
• postgres_exporter (prometheus-community) on GitHub
• mysqld_exporter (Prometheus) on GitHub
• sql_exporter (burningalchemist) on GitHub
• Grafana Alloy: prometheus.exporter.mssql
• Grafana on GitHub (licence)
• Datadog documentation: Database Monitoring
• Datadog documentation: Setting up DBM for self-hosted Postgres
• Datadog documentation: Correlate DBM and APM
• Datadog documentation: OpenMetrics integration
• Datadog pricing list

Checked October 2026.

How we research comparisons: our editorial method.