Prometheus vs Grafana

This is the most common false rivalry in self-hosted monitoring. Prometheus and Grafana are not two answers to the same question — they are two halves of one answer. Prometheus is the database: it scrapes your services over HTTP, stores the numbers as time series, and evaluates alerting rules against them. Grafana is the front end: it queries a database it does not own and turns the result into dashboards, panels, and alerts a human will actually look at. People search for "Prometheus vs Grafana" because they arrive at both names at once and assume they must choose. Usually you shouldn't.

What each one does when it's alone

Prometheus on its own is a complete monitoring system, just an austere one. It discovers targets, scrapes their metrics endpoints on an interval, keeps the data in its own time-series database, and lets you interrogate it in PromQL through a built-in expression browser. That browser will draw a graph — one query, one graph, no saving, no layout. Pair it with Alertmanager and you get routing, grouping, silencing, and delivery to email or chat. Nothing about that setup needs Grafana. It is what you run when you want to be paged correctly and are content to write a query when you need to look at something.

Grafana on its own does not monitor anything, because it stores nothing. Point it at no data source and it is an empty shell. What it brings is the query-and-render layer for whatever is storing your data — Prometheus, but equally Loki for logs, InfluxDB, Postgres, Elasticsearch, and dozens more. Modern Grafana also has its own unified alerting engine, so alerts no longer have to live in Prometheus rules. That is the important nuance: Grafana has not needed Prometheus specifically for a long time. It needs a backend.

Where the data lives is the whole distinction

Everything else follows from storage. Prometheus owns a TSDB on local disk, with a retention window you configure and a pull model that decides what gets collected. That ownership is why Prometheus is the piece you can't casually swap: your history is in it, your scrape config defines your coverage, and your recording rules shape what's cheap to query later.

Grafana keeps only dashboards, users, and alert definitions — its own small database, usually SQLite, sometimes Postgres. Losing a Grafana instance costs you dashboards, which are re-creatable and provisionable from files. Losing a Prometheus instance costs you history. Size and back them up accordingly: 2 GB of RAM for Prometheus is the sane floor and it grows with active series, while Grafana is comfortable at 1 GB more or less regardless of how much data sits behind it.

Licensing, which is not symmetrical

Prometheus is Apache-2.0 and a graduated CNCF project — permissive, no commercial tier, no feature gating. Grafana is AGPL-3.0, a network copyleft license. For self-hosting it for your own team this changes nothing at all. It matters if you plan to embed Grafana inside a product you distribute or offer as a service, where AGPL obligations attach. Grafana Labs also sells a cloud and an enterprise edition with extra data-source plugins and reporting, so a few features you read about in their docs aren't in the OSS build.

Running them together, which is the normal case

The default stack is Prometheus scraping, node_exporter and per-service exporters exposing, Alertmanager routing, and Grafana on top for dashboards. On a single VPS all four fit comfortably; budget for Prometheus, since it is the one whose memory grows with the number of series you collect. Provision Grafana's dashboards and data sources from config files rather than clicking them in, and the whole thing becomes reproducible.

Two decisions are worth making deliberately. First, where alerts live: Prometheus rules plus Alertmanager give you alerting that survives Grafana being down, which is the right default when Grafana is the thing most likely to be restarted. Second, retention: Prometheus is not built for years of data, so if you need long history, plan for a remote-write backend rather than a very large local disk.

If you genuinely must run only one

Run Prometheus. It collects, it stores, it alerts, and its expression browser is enough to answer a question during an incident. It is ugly and it is sufficient. Grafana without a backend cannot tell you anything about your servers, so "just Grafana" is only a real option when something else — a hosted metrics service, an existing Influx or SQL database, a Netdata agent forwarding out — is already doing the storing. That case exists and it's legitimate; it just isn't the one most people asking this question are in.

Pick Prometheus if…

• You need the piece that collects and stores metrics, and something has to do that before anything can draw a chart.
• You want alerting that runs independently of your dashboard layer, via rules and Alertmanager.
• You're running one tool and it has to be the self-sufficient one.

Pick Grafana if…

• Your metrics already live somewhere and what you lack is dashboards.
• You need one view across several backends — metrics, logs, and SQL in the same pane.
• Dashboards and alert management need to be usable by people who won't write PromQL from memory.