.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Grafana vs Prometheus is a versus that mostly is not one. Prometheus scrapes and stores metrics. Grafana reads them back and draws them. Together they are the default open source metrics stack, and the honest answer to "which one can I skip" is usually neither.
The real choices sit in alerting and in long-term storage. This page covers the architecture first, because once you can see where the data physically sits, most of the rest answers itself.
What Prometheus does
Prometheus is a metrics server. It discovers targets, pulls a plain text page of numbers from each one over HTTP (usually /metrics) and appends the samples to a local time series database on disk. It evaluates recording rules and alerting rules against that database on a timer, and it answers PromQL queries over an HTTP API. That is the whole product.
Prometheus pulls. It reaches out to your services on a schedule you set with scrape_interval, so every target has to be reachable from the Prometheus host. Nothing pushes into it by default, which is why short-lived jobs need the Pushgateway and why a firewall rule you forgot shows up as a target in the down state rather than as missing data.
The 3.x series changed more than the version number suggests. The Prometheus 3.0 announcement lists the full set of breaking changes, and it is the thing to read before an upgrade from 2.x. Metric and label names accept the full range of valid UTF-8 characters instead of forcing underscores, remote write 2.0 carries metadata, exemplars, created timestamps and native histograms, and the server acts as a native receiver for OTLP metrics. Native histograms themselves are still behind a feature flag, so treat them as experimental in anything you page on.
That UTF-8 change sounds cosmetic and is not. Metric names arriving from OpenTelemetry carry dots, and every bridge that rewrote those dots into underscores was a place where two systems quietly disagreed about what a metric was called. Anyway, versions.
On versions: the project ships a minor release every six weeks and marks occasional releases as LTS with a year of bug and security fixes. As of August 2026 the Prometheus download page lists 3.14.0 as latest, with 3.13 and 3.5 carrying the LTS label. On a server you are not babysitting, run an LTS.
What Grafana does
Grafana stores no metrics. It holds dashboards, users, teams, folders, permissions, alert rules and data source definitions in its own backend database, which is SQLite by default and MySQL or PostgreSQL for anything serious. Every number you see on a panel was fetched from somewhere else, live, when the panel loaded.
The layer around the query is what you get for the extra complexity: saved and versioned dashboards, template variables, a permission model, provisioning from YAML, unified alerting with contact points and templates, plus roughly twenty core data sources shipped in the box. The core set covers Prometheus, Graphite, InfluxDB, OpenTSDB and the three big cloud metric APIs for time series, Loki and Elasticsearch for logs, Jaeger, Tempo and Zipkin for traces, plus MSSQL, MySQL and PostgreSQL for anything that speaks SQL.
So Grafana is a read and render layer with an access control system bolted to it.
How Prometheus and Grafana connect
You add a Prometheus data source in Grafana pointing at http://localhost:9090, a step building a Grafana dashboard from Prometheus data walks through screen by screen. From then on Grafana sends PromQL strings to Prometheus over HTTP and gets JSON back. The query runs inside Prometheus, on the Prometheus host, using Prometheus memory. Grafana posts the query and paints the result. The wiring is thinner than most diagrams of it.
curl -s 'http://localhost:9090/api/v1/query?query=up' | head -c 400If that returns JSON on the Prometheus host, Grafana will work once it can reach the same URL. Most "data source is not working" tickets end at that one command. The failure is nearly always network reachability from Grafana's own namespace.
Two consequences fall out of this design. Losing Grafana loses your dashboards and alert rules but not one sample of metric data. Losing Prometheus loses the data itself, and your dashboards go blank while staying perfectly intact. Back up both: /var/lib/grafana for one, the Prometheus data directory for the other.
The Prometheus expression browser versus Grafana panels
Prometheus ships its own web UI on port 9090, and since the 3.0 redesign it is a decent place to work. You get a query field with autocompletion, a tree view that breaks a PromQL expression into its parts so you can see which selector returned nothing, a target list showing scrape health, and a rules page.
I use it constantly, but only for debugging. It saves nothing. There are no dashboards, no users, no sharing, no time range you can hand to a colleague in a URL that survives a restart. The expression browser is where you find out that your rate() window is shorter than your scrape interval; Grafana is where the result of that discovery lives afterwards.
Keep port 9090 bound to localhost or behind your firewall and let Grafana be the only thing exposed. There is no authentication in front of the Prometheus UI and its /api/v1/admin endpoints can delete series, so leaving it open on a public IP is a bad afternoon waiting to happen. The same reasoning applied to the Grafana side is in hardening a Grafana server, which covers a good deal more than port binding.
Alerting: Alertmanager or Grafana unified alerting
Both answers here are defensible.
Prometheus evaluates alerting rules from its own config and pushes firing alerts to Alertmanager, a separate daemon that handles grouping, inhibition, silences and routing to receivers. Alertmanager is deliberately narrow and very good at the specific job of not drowning you. Grouping folds a hundred alerts from one rack into a single notification. Inhibition mutes the symptom alerts when the cause is already firing, and clustering keeps notifications deduplicated across replicas.
Grafana's unified alerting handles two rule types. Grafana-managed rules are evaluated by Grafana itself and can combine queries and expressions from several data sources in one rule, which Prometheus structurally cannot do. Data source-managed rules are the Prometheus, Mimir or Loki rules, edited through the Grafana UI and pushed down to the data source that evaluates them.
How I split it: anything that needs to fire while Grafana is being restarted or upgraded belongs in Prometheus rules with Alertmanager delivering. Setting up Grafana email alerts covers the delivery side of the other path, contact point templates included. Anything that spans data sources, needs a templated message or needs a non-engineer to edit it, belongs in Grafana-managed rules. Running the same alert family in both places gets you duplicate pages and a rule you keep fixing in whichever copy is not firing.
Storage: plain Prometheus, remote write and Mimir
Prometheus TSDB is local, single node and not clustered. That is a design decision rather than an oversight: replication is somebody else's problem, which keeps the server simple and reliable. For most single-server or small-fleet setups it is the right amount of machinery. Set --storage.tsdb.retention.time to something honest and move on.
When you outgrow it, the escape hatch is remote_write, which streams samples to a long-term store while the local TSDB keeps a short window. Grafana Labs ships Mimir for that role: horizontally scalable, multi-tenant, PromQL-compatible long-term storage for Prometheus and OpenTelemetry metrics, sitting on object storage and licensed AGPLv3 like Grafana itself.
Do not put Mimir on a single VPS because a blog post said Prometheus does not scale. Mimir pays off at multi-tenant scale or when you need years of retention with high availability. A single Prometheus on NVMe with ninety days of retention covers far more ground than people expect, and the arithmetic is public. The Prometheus storage docs give the formula needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample and note that Prometheus stores an average of only 1 to 2 bytes per sample.
Run that for a realistic case. One host exporting around 1,000 node_exporter series at a 15 second scrape interval produces about 67 samples a second. Over thirty days at two bytes a sample that is roughly 350 MB. Ten hosts, still under 4 GB. What pushes people off single-node Prometheus is label cardinality and memory. I do not know if that 1 to 2 bytes figure still holds once native histograms are in play, and I have not measured it.
Using Grafana without Prometheus
Plenty of Grafana instances never touch Prometheus. Point Grafana at a read-only PostgreSQL user, write ordinary SQL with a $__timeFilter macro, and you have a live business dashboard with no exporter and no metrics pipeline anywhere. Signups per day, queue depth, failed payments, all straight from the application database. The SQL data sources get less attention than they have earned.
Same story for logs through Loki or Elasticsearch, for cloud metrics through the CloudWatch and Azure Monitor data sources, and for InfluxDB where the data is already time series but written by something that pushes rather than something that gets scraped. A Grafana with a Postgres data source and no Prometheus is a completely normal deployment, and installing Prometheus alongside it would add a daemon that collects nothing anybody looks at.
Resource footprint on a small VPS
The numbers from earlier sections, collected. Prometheus serves its UI and its query API on port 9090. Grafana's minimum recommended memory is 512 MB with one CPU core. Prometheus stores an average of 1 to 2 bytes per sample. Grafana's own state lives in /var/lib/grafana and the samples live in the Prometheus data directory.
Both are modest. An idle Grafana with a handful of dashboards sits comfortably inside that 512 MB. Its CPU cost is bursty and lands when someone loads a dashboard with twenty panels.
Prometheus memory tracks active series, not scrape volume. A few thousand series is tens of megabytes of head block; a badly designed label with a user ID or a request path in it will take you into gigabytes without warning. When a Prometheus process starts growing steadily, look at topk(10, count by (__name__)({__name__=~".+"})) before you look at the server size.
For a two gigabyte VPS running Grafana, Prometheus and node_exporter together, disk on the default 20 GB image usually runs out before RAM does. Installing Grafana on an Ubuntu VPS has the full path for that setup, and monitoring a Node.js app with Prometheus and Grafana works the same box end to end with an application on top. Size the disk before the RAM.
Which one to pick
Run Prometheus on its own if you are one person watching one system, comfortable in the expression browser, with every alert you care about expressible as a PromQL rule that Alertmanager delivers. This is a real configuration and it is not a compromise. Adding Grafana to it buys you nothing except another service to patch.
Add Grafana the moment a second person needs to look at a graph. Same for a saved view that survives a browser tab, or alert notifications carrying a message someone can read at 3am without knowing PromQL. Also add it when your data is spread across more than one system, because correlating a Prometheus counter with a Postgres table in one dashboard is exactly what Grafana exists for.
Run Grafana on its own when your numbers already live somewhere queryable. SQL databases, Elasticsearch, a cloud provider's metrics API, an InfluxDB that something already pushes to. Standing up Prometheus in that situation adds a scraper with nothing to scrape.
Run both, which is what most people end up doing, when you want the collection model Prometheus is good at and the presentation and access control Grafana is good at. Grafana Cloud versus self-hosted Grafana weighs up the managed version of that trade for anyone who would rather not maintain either, and the complete Grafana guide holds the wider set of choices this one sits inside.
