It's because it was built with high granularity and unlimited metrics as a key differentiator from the beginning. The core is written in pure C, optimized to death. Even long-term retention was initially sacrificed, in order to be able achieve that high performance, with minimal resource needs.

Long term retention is now possible, but with relatively high memory requirements, depending on how many metrics are collected. Again, it was a decision to never give up realtime granularity and speed, even at the cost of writing our own timeseries db in C and utilizing more memory.

Prometheus is designed around metric centralization and running a scraper at some interval (every 15s). Netdata was originally focused on running on a single node and collecting at small intervals. Centralizing that data every second is a separate task, and you could avoid it with Netdata simply by viewing Netdata on the node in question. Netdata can also be configured to stream data to a central node.

The centralized pull architecture of Prometheus does not lend itself towards small interval updates or towards resiliency (you actually need to run 2 Prometheus and double scrape for that).

I doesn't store much history from what I can tell. If you don't have years worth of data points then having 15 times as many isn't a big deal.

And people are somehow meant to only monitor a single server?

There's a reason timeseries databases are trying to get downsampling right.

It's a locally installed agent that monitors and serves metrics on the same host. If you want to monitor multiple hosts then you can either visit the dashboards individually, or scrape the APIs and put the metrics on a combined dashboard - which is what Netdata Cloud is.

it polls every second, to get metrics every second. genius, i know?