Netdata vs Prometheus and Grafana

This is not a like-for-like comparison and pretending otherwise is why most articles about it are useless. Netdata is one thing you install. Prometheus and Grafana are two things that do half a job each, and in practice you also run node_exporter, cAdvisor and usually Alertmanager, so the honest comparison is one container against five.

Here is the position, stated before the evidence. For one machine, or three, install Netdata and stop. Build the Prometheus stack when you have a specific question it answers that Netdata cannot, and you can name the question.

What the specification table decides#

Compare the two Idle memory figures for Prometheus and Grafana and then add them, because you never run one without the other, and then add node_exporter and cAdvisor on every host. Services to run is the row that tells the real story: Prometheus is listed at two because it is useless without at least one exporter, and a working homelab deployment is four or five. Operational load puts Netdata and Grafana at 2 and Prometheus at 3, which is the same conclusion from a different angle.

The uncomfortable part: you will stop looking at the dashboards#

Search "homelab Prometheus Grafana" and you get a hundred tutorials ending with a screenshot of a dashboard nobody opens again. The pattern is consistent and worth naming, because it is the actual outcome for most single-operator setups:

1. You install Prometheus, node_exporter, cAdvisor and Grafana over a weekend.
2. You import dashboard 1860 from the Grafana library and it looks superb.
3. Three weeks later something breaks, you SSH in and run htop and docker logs, because that is faster than finding the right panel.
4. Six months later you notice the dashboard has been broken since a major upgrade and you did not miss it.

The reason is that dashboards answer questions you already knew to ask. What you actually need at 2am is either an alert that fired without you writing a rule, or a view of everything on one machine at once. Netdata is built for exactly those two things, and the Prometheus stack is built for neither by default: Prometheus ships no alerting rules at all, and Grafana ships no dashboards.

If you never write an alert rule, the stack you built is a screenshot generator. Be honest about whether you are going to write them.

What Netdata costs, precisely#

The published figures: about 150 MiB of RAM by default, roughly 100 MiB with machine learning and alerts disabled, about 5% of one core on production systems and under 1% with ML and alerts off. Disk defaults to 1 GiB per tier across three tiers, plus metadata, so about 4 GiB total, giving 14 days at per-second resolution, 3 months at per-minute and 2 years at per-hour.

That last line is the fact most Netdata comparisons get wrong: Netdata is not a "live view only" tool. Two years of hourly data by default is longer retention than a stock Prometheus, which keeps 15 days.

On small hardware, trim it rather than skipping it:

# /etc/netdata/netdata.conf
[db]
    mode = dbengine
    storage tiers = 2
    dbengine tier 0 retention size = 256MiB
    dbengine tier 1 retention size = 256MiB
    update every = 2

[ml]
    enabled = no

Halving the update frequency roughly halves CPU. Dropping to two tiers and 256 MiB each takes disk from about 4 GiB to well under 1 GiB. On an SD card, go further: set the database mode to ram or alloc and stream to a parent node, which removes agent disk writes entirely.

Two things people install Netdata into without reading:

• Port 19999 has no authentication. Not a bug, a design decision. It exposes process lists, running containers, network connections and the full metrics API to anyone who reaches it. Bind it to localhost in netdata.conf and put it behind Caddy with auth, and never map it to a public IP. See Reverse proxy and TLS.
• The container needs to be nearly privileged. The documented compose uses pid: host, network_mode: host, cap_add of SYS_PTRACE and SYS_ADMIN, apparmor unconfined, and read-only mounts of /, /proc, /sys, /etc/passwd, /var/log and the Docker socket. Without those, container and per-application metrics are simply missing with no error explaining why. If your security posture rules that out, install the native package on the host instead of running a half-crippled container.

What the Prometheus stack costs, precisely#

Prometheus itself is modest: 150 MB idle, well under 1 GB for a homelab with a handful of exporters. Grafana is another 150 to 400 MB. node_exporter and cAdvisor add maybe 60 MB between them. Alertmanager adds 30 MB. Call it 700 MB to 1 GB across five containers, against Netdata's 150 MiB in one.

The cost that actually bites is not memory:

• Retention defaults to 15 days with no warning, and in current 3.x the command line flags are deprecated in favor of storage.tsdb.retention.time and .size in the config file.
• The default example config scrapes every 15 seconds. Every scrape appends to a write-ahead log; the head block flushes every two hours; compaction rewrites blocks after that. That write pattern kills SD cards in four to twelve months. Use 60 seconds for host metrics and put /prometheus on an SSD.
• Cardinality, not volume, is what kills it. One label with unbounded values, a container ID or a request path, turns one metric into tens of thousands of series and the process starts eating gigabytes. Check prometheus_tsdb_head_series after adding any exporter and drop offending labels with metric_relabel_configs.
• The official image runs as nobody and declares a volume at /prometheus, so a bind mounted host directory fails to start until you chown 65534:65534 it. Grafana's equivalent is uid 472.
• Grafana 12 removed AngularJS entirely in May 2025, so any community panel plugin that never got a React rewrite renders as an error. Inventory your plugins before a major upgrade, because there is no toggle to put it back.

Set retention and scrape interval properly on day one:

global:
  scrape_interval: 60s
storage:
  tsdb:
    retention:
      time: 180d
      size: 20GB

None of this is hard. It is just work, and it is work you keep doing: rule files, exporter versions, dashboard JSON, one-way Grafana schema migrations that cannot be rolled back against a migrated grafana.db.

What the stack genuinely does better#

Three things, and they are real:

1. Queries across machines. PromQL over twenty hosts answers "which of my machines had disk latency above 20ms last Tuesday" in one expression. Netdata's answer to multi-node is streaming children into a parent, which gives you a combined view but not a query language.
2. Retention you choose. 180 days at 60 second resolution is a config line. Netdata's tiering gives you long retention only at degraded resolution.
3. Alerts on things Netdata does not know about. Anything that exposes /metrics becomes alertable: a backup job's last-success timestamp, a queue depth, a certificate expiry from blackbox_exporter. Netdata's hundreds of built-in alarms cover the machine, not your application.

If none of those three sentences describes a problem you have, you do not need the stack.

Grafana is worth a note on its own: it is never the answer by itself, because with no data source configured it is an empty shell. It has been AGPLv3 since April 2021, current at 13.2.1 (September 2026), and everything a single operator needs is in the free build including unified alerting and OIDC login. Enterprise gates SAML, role-based access control, data source permissions, query caching, reporting and about 40 commercial data source plugins. Note also that the published Enterprise image runs with free features until a licence is applied, so pin the OSS image explicitly if licence compliance matters.

Run both, which is what experienced operators do#

The combination that works: Netdata on every host for interactive diagnosis and built-in alarms, Prometheus scraping a narrow selection of series for long retention.

scrape_configs:
  - job_name: netdata
    metrics_path: /api/v1/allmetrics
    params:
      format: [prometheus]
      source: [average]
    scrape_interval: 60s
    static_configs:
      - targets: ['nas:19999', 'web1:19999']
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'netdata_(system|disk_space|mem)_.*'
        action: keep

That gives you every Netdata collector as a Prometheus source without writing a single exporter config, and the keep rule stops cardinality from exploding. It is a better use of a weekend than assembling node_exporter and cAdvisor by hand.

Which one for your situation#

What to do next#

Install Netdata on your busiest machine, look at it for a week, and write down every question it could not answer. If the list is empty, you are finished and you saved a weekend. If the list has three real entries, you now have the requirements for a Prometheus deployment and you will build the right one instead of importing dashboard 1860.

Either way, read The minimum viable monitoring stack first, because metrics are only one of the three legs. You also need uptime checks that alert (Uptime Kuma vs Gatus), logs you can read when something breaks (Dozzle), and disk health that warns you before a drive dies (Scrutiny). If Netdata is too heavy for your hardware, Beszel vs Netdata covers the tier below it. The full Monitoring category has every profile, and Stack planner will tell you what the whole set costs in RAM before you deploy it.