Prometheus vs Grafana: which one collects metrics and which one shows them
Prometheus collects, stores and alerts on metrics, while Grafana builds dashboards and alerting views over Prometheus and many other sources. Because they do different jobs, many teams run both, but a single team may not need Grafana at all, and a team that needs Grafana may still need Prometheus underneath it. The first question is not which tool is better but which jobs your team actually has to do.
The decision turns on three questions. First, who reads the data: if operators only need查询 access through the Prometheus web UI or an existing alerting path, Prometheus alone may be enough, while shared dashboards for engineers, managers and on-call staff usually call for Grafana. Second, whether data sources beyond Prometheus matter: Grafana can query other stores, so if logs, traces or a SQL database must appear on the same screen, the visualization layer earns its place. Third, who runs each component. Prometheus stores its local data on a single node that is not clustered or replicated, and Grafana needs MySQL or PostgreSQL for production and high availability, so every component you add is one more thing to back up, patch and upgrade.
Before you commit, confirm the licensing and identity requirements with each vendor. Grafana is offered under AGPLv3 in its open-source build, and SAML, team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so check whether your single sign-on standard is covered in the edition you plan to run. Prometheus is Apache-2.0 with no paid edition. Also decide where alerts will be routed through Alertmanager, since duplicate notifications are a known HA concern in Grafana. A written scope that names the readers, data sources and owners of each component will make the rest of the comparison concrete.
Which platform fits which team situation
This table matches common team situations to the platform that fits better and the condition that decides it. Prometheus collects and stores metrics, while Grafana gives people dashboards, data source access and login options, so many teams run both. The main takeaway is that Prometheus decides what is collected and stored, while Grafana decides who sees it and how.
| Team situation | Better fit | Condition that makes it so |
|---|---|---|
| Platform team with only Prometheus metrics | Prometheus and Alertmanager, without Grafana at first | Engineers are comfortable with PromQL and alerts only need routing to on-call channels |
| Logs and traces held in other stores | Grafana, alongside Prometheus and separate log and trace stores | Prometheus holds metrics only, so logs and traces need stores such as Loki or OpenSearch queried from Grafana |
| Shared dashboards for non-engineers | Grafana | Managers and support staff need browsable dashboards and filtered views rather than writing PromQL |
| Regulated team needing SSO | Grafana, with the edition chosen for the identity provider | Entra ID, Okta and similar providers work in all editions, but SAML, team sync and SCIM need Grafana Enterprise |
| Access control for Prometheus endpoints | Both, with an authenticating proxy in front of Prometheus | Confirm the endpoint protections in the Prometheus security model against your audit policy before rollout |
| Dashboards managed as code | Grafana with provisioning | Data sources and dashboards load from YAML or JSON files at startup, which suits version-controlled setups |
| Longer metric retention or high availability | Prometheus with remote write, and Grafana on MySQL or PostgreSQL | Default local retention is 15 days and Prometheus storage is not replicated, while Grafana HA needs a shared database |
How each component is built and what it means for operations
Prometheus and Grafana fail in different ways and need different care. Prometheus keeps its own local storage and alerting path, while Grafana depends on an external database and a load balancer when it runs in high availability. The cards below cover the decisions each component forces on the team that runs it.
Prometheus local storage in two-hour blocks
Prometheus writes samples to a local time series database organized into two-hour blocks, with a write-ahead log protecting recent data. Each block is a unit the server compacts and deletes as retention ages out. For operators, this means disk sizing, filesystem health and backup of the data directory are direct responsibilities of the Prometheus host. Check the disk growth rate against your active series count before you size volumes, and confirm how you will restore a failed server's data if you need history after an outage.
Default retention and its limits
The default retention is 15 days, and you can set it by time or by size. Grafana dashboards only show what Prometheus still holds, so a dashboard that looks back 30 days will show gaps unless you extend retention or add long-term storage. Retention is a cost decision as well as a visibility one. Decide how far back incident reviews and capacity planning need to reach before you accept the default, and document who approves changes to it.
Single-node storage with no replication
Local storage is not clustered or replicated, and the Prometheus documentation says to manage it like any other single-node database. A host outage stops collection for that server until it returns, and the samples it missed are not recovered from a peer. Teams that need continuous history usually run a second Prometheus, or send samples through remote write to external long-term storage. Ask who owns failover for each Prometheus host and whether alert coverage survives its loss.
Alertmanager clustering and its flags
Alertmanager groups, inhibits and silences the alerts that Prometheus sends, and it can run as a cluster for high availability through its --cluster flags. Prometheus should list every Alertmanager instance directly rather than send alerts through a load balancer. Operators need to configure peer discovery, confirm that each Alertmanager receives alerts, and test that notifications are not duplicated or lost. Grafana alerting is a separate path, so the two alert sources need to be reviewed together during on-call handover.
Grafana configuration database choice
Grafana stores its configuration in SQLite 3 by default, and it can also use MySQL 8.0 or later or PostgreSQL 12 or later. The installation documentation says SQLite does not scale for production, so a production or high availability deployment needs MySQL or PostgreSQL. Operators must provision and back up that database, plan its upgrades, and decide who restores it after a failure. Confirm the database version against the supported range before you commit to a platform.
Grafana high availability behind a load balancer
Grafana high availability runs two or more active-active servers behind a load balancer, sharing one MySQL or PostgreSQL database, with database-backed auth tokens so users can reach any node. The documentation notes that alerting needs extra configuration to avoid duplicate notifications, and that Grafana Live has limitations in this mode. Operators own the load balancer, session behavior and the duplicate-alert check. Ask your team to test a node failure during an active dashboard session before relying on the setup.
Capabilities side by side: collection, storage, query and visualization
This table compares what each tool does in a monitoring stack, from collecting and storing metrics to querying, alerting and authentication. Read it as a division of labor: Prometheus owns collection and storage, while Grafana owns dashboards and access to many sources. The main takeaway is that the two are complementary, and the authentication and provisioning rows show where licensing changes what you get.
| Capability | Prometheus | Grafana |
|---|---|---|
| Role | Collects, stores and evaluates metrics | Visualizes and explores data from many sources |
| License | Apache-2.0, with no paid edition of the project | AGPLv3 for core, with Grafana Enterprise as a non-AGPL commercial option |
| Query language | PromQL | Queries sent to each connected data source in its own language |
| Data sources | Scrapes HTTP targets found by service discovery or static config, plus pushes via a gateway | Connects to Prometheus and many other sources |
| Storage model | Local time series database in two-hour blocks, default 15-day retention, not clustered or replicated | Stores its own configuration in SQLite 3, MySQL 8.0+ or PostgreSQL 12+, with SQLite not for production |
| Alerting | Rules evaluated by Prometheus, with notifications sent to Alertmanager | Grafana alerting, which needs extra configuration for high availability to avoid duplicate notifications |
| Configuration as code | Configuration files managed alongside the server | Provisioning from YAML or JSON at startup, with Terraform and Git Sync documented |
| Authentication | Access control is set up outside the project, per its security model | LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth in all editions; SAML, team sync, active sync and SCIM only in Enterprise and Grafana Cloud |
What each license allows and what is paid for
Prometheus is licensed under Apache-2.0, a permissive license that allows you to run, modify and redistribute the software in commercial settings, subject to its notice and attribution terms. The project has no paid enterprise edition, so the license itself carries no fee. Your spending goes to the infrastructure that runs it, the storage that holds its data, the implementation work and the staff who operate it.
- No license fee: Apache-2.0 places no per-server, per-user or per-series charge on the core project.
- No paid edition: There is no commercial tier of Prometheus to buy, so support must come from a vendor or partner you contract separately.
- Recurring costs: Compute, disk, backups and on-call time recur every month, and they grow with the number of series and the retention you set.
- One-time costs: Design, exporter selection, alert rule authoring and initial dashboards are typically one-time implementation work.
- Local storage limits: The storage docs say local storage is not clustered or replicated, so any high availability or long-term retention design adds components you must pay to run.
Before shipping modified code, confirm that your notice and attribution obligations under Apache-2.0 are met, and check the release cycle for the line you run, since minor releases stop receiving bug fixes after six weeks.
On April 20, 2021, Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3. The AGPL is a strong copyleft license: if you modify Grafana and make it available to users over a network, you must offer those users the corresponding source of your modified version. Plugins, SDKs and agent software kept other licenses, so each component you install needs its own check.
- Free to self-host: The open-source build of Grafana carries no license fee, and its costs are the server, the database and staff time.
- AGPL network clause: Internal use alone does not trigger source offers, but a modified build exposed to external users may.
- Database requirement for production: The installation docs say SQLite does not scale for production, so MySQL 8.0 or later or PostgreSQL 12 or later is needed for production and high availability.
- Authentication limits: LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT are available in all editions, but SAML, team sync, active sync and SCIM are not.
- Support is separate: Community use has no vendor support contract, so you must arrange it yourself.
Confirm your modification and distribution plans with counsel before you ship a changed build, and check each plugin's license separately.
Grafana Enterprise is offered as a commercial option that is not licensed under AGPL, and it is the route to SAML, team sync, active sync and SCIM provisioning. Grafana Cloud is a hosted service with its own pricing tiers, so moving to it changes who runs the platform and what recurs on the invoice. The pricing page lists the figures below, and the amounts can change, so check them before budgeting.
- Cloud free tier: The pricing page lists a free tier for Grafana Cloud.
- Cloud Pro tier: The pricing page lists a Pro tier starting with a 19 US dollar monthly platform fee, plus usage charges.
- Cloud Enterprise tier: The pricing page lists a minimum commitment of 25,000 US dollars per year.
- Enterprise terms: Enterprise pricing and license terms are negotiated with Grafana Labs, so ask for a written quote that names included features and support levels.
- Recurring costs: Cloud usage and Enterprise subscriptions recur, while self-hosted Enterprise adds subscription fees on top of your own infrastructure costs.
Source these figures from the Grafana pricing page when you prepare a budget, and ask Grafana Labs to confirm which features each Enterprise and Cloud tier includes.
What drives the running cost of each platform
Prometheus has no license fee, so its running cost is infrastructure and the people who operate it. The project is Apache-2.0 licensed and has no paid enterprise edition, so the spend lands on the servers that scrape targets and hold the local time series database, the disks behind it, and any long-term storage you add through remote write. Local storage is not clustered or replicated, so a durable design usually means more than one Prometheus server, separate retention settings, and possibly an external store. Costs rise with the number of active series, scrape interval and retention period, which the Prometheus storage documentation ties to the default 15-day retention that you can change by time or size. Ask your implementer to size storage from your own series count and retention target, and to price the cost of a second Prometheus instance for failover as a recurring item.
Grafana adds a database, load balancer and upgrade effort that recur for as long as the dashboards matter. The open-source build is AGPL-3.0 licensed, so the license itself costs nothing, but production use needs MySQL 8.0 or later or PostgreSQL 12 or later, because the installation docs say SQLite does not scale for production. High availability means two or more active-active Grafana servers behind a load balancer sharing that database, so you pay for the database service, its backups, and the load balancer in your environment. Upgrades also recur: Grafana documents a major release once a year, minor releases every other month, and patch releases at least monthly, with each minor release supported for 9 months. Each cycle needs staging, testing of provisioned dashboards, and a rollback plan, and the alerting configuration needs attention to avoid duplicate notifications in an HA setup.
Enterprise and Cloud subscriptions are the cost line most likely to change the total, so get them in writing. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so if your identity team requires them, the subscription becomes a recurring cost rather than an option. The Grafana pricing page lists a Pro tier with a 19 US dollar monthly platform fee plus usage and an Enterprise tier with a minimum commitment of 25,000 US dollars per year, and those figures should be checked against the current page before you budget. A written quote from DeployOpen follows the agreed scope and should separate one-time items (architecture, installation, provisioning as code, HA setup, hardening) from recurring items (upgrades, patch cycles, retainer support, on-call coverage). Ask for the assumed Prometheus series count, the database and load balancer you will provide, the upgrade frequency covered, and which Grafana edition the quote assumes.
Adding Grafana to an existing Prometheus setup
This sequence moves a team from Prometheus alone to Prometheus with Grafana on top, keeping the metrics store and query language in place while rebuilding the visual and alerting layers in a reviewable, repeatable form.
Confirm Prometheus version and retention
The platform owner records the running Prometheus version, the retention settings (time or size), and whether the server is a single node. Prometheus stores data in a local time series database with a default retention of 15 days, and its storage docs state that local storage is not clustered or replicated, so a single server holds the only copy of recent history. Check the version against the release cycle page to confirm it is on a supported minor or the current LTS line (3.13 at the time of writing). Done when the team has a written note of version, retention, and the query window its dashboards need, since Grafana will only show what Prometheus still holds.
Connect Grafana to Prometheus as a data source
An administrator installs Grafana, picks a backing database (SQLite is the default, but the installation docs say it does not scale for production, so MySQL or PostgreSQL is needed for production and high availability), and adds Prometheus as a data source using its HTTP URL. The PromQL queries used in existing rules and ad hoc questions transfer unchanged, because Grafana sends them to the same Prometheus API. What must be checked is network reachability from Grafana to Prometheus, any authentication placed in front of Prometheus, and the data source time range. Done when a test query returns series in Explore and the results match the same query run directly against the Prometheus web interface.
Rebuild or import dashboards
Teams either recreate dashboards by hand in Grafana or import dashboard JSON, then point panels at the new Prometheus data source. PromQL expressions carry over, but variables, data source references, panel layouts and any templating built around Prometheus labels usually need adjustment after import. Review each imported panel for queries that depend on series retained only by the old setup, and for dashboards that assume a longer window than the Prometheus retention allows. Done when each dashboard in scope loads without errors and a sample of panels shows values that match the source tool for the same time range.
Move alert views and notification routing
Alert rules written in Prometheus keep evaluating in Prometheus, and Alertmanager continues to group, inhibit and silence them. Grafana can display Prometheus alert state, but the team must decide which system owns each alert and notification path so the same event does not page twice. Confirm that Prometheus points at every Alertmanager instance, and that any Grafana-managed alert rules, contact points and notification policies are reviewed for duplicate routes. The Grafana high availability docs note that alerting needs extra configuration to avoid duplicate notifications when several Grafana servers run. Done when a test alert reaches the intended receiver exactly once and the owner of each alert path is written down.
Confirm authentication and access model
The security owner maps who needs Grafana access and which login method applies. Per the Grafana authentication docs, LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT work in all editions, while SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. Teams should also apply the hardening settings in the security hardening guide, such as secure cookies, a Content Security Policy and authentication on the metrics endpoint. Done when a test user from each role signs in through the chosen method and sees only the folders and data sources granted to that role. Confirm the group-to-role mapping with the identity provider owner before go-live.
Add provisioning or as-code management
Once the data sources, dashboards and alerting resources work, the team moves them into files. Grafana provisioning loads data sources, dashboards, plugins and alerting resources from YAML or JSON at startup, so the configuration lives in Git and reproduces on a rebuilt server. Grafana also documents further as-code options, including Terraform and Git Sync, which the team should evaluate against its own change process. Exported dashboards can then be reviewed in merge requests like any other configuration. Done when a fresh Grafana instance built only from the repository reproduces the data sources and dashboards, and the team has recorded which resources remain edited by hand so drift can be detected.
Document ownership and upgrade cadence
The team records who maintains Prometheus, Alertmanager and Grafana, and sets an upgrade process for each. Grafana's upgrade guidance describes major releases once a year, minor releases every other month, and patch releases at least monthly, with each minor supported for 9 months. Prometheus LTS releases receive fixes for one year, while regular minors stop receiving fixes after six weeks. Because the two projects follow different schedules, the runbook should name the version each component is pinned to and the trigger for upgrading. Done when the runbook is reviewed by the on-call team and a first upgrade has been rehearsed in a non-production copy.
Where implementation projects usually run long
Most of the schedule risk sits in the work around the two tools rather than in installing them. On the Prometheus side, the effort is in deciding what to scrape: exporters for each host, database and application, service discovery rules that keep targets current, and label conventions that stay consistent across teams. Retention is the sizing decision most often made too late. Prometheus defaults to 15 days of local retention, configurable by time or size, and its storage docs state that local storage is not clustered or replicated. Confirm your retention target, disk budget and any remote write destination for longer history before the first production scrape, because changing them later means re-planning storage. Alertmanager needs its own design, including the cluster flags for high availability and the rule that Prometheus should target every Alertmanager instance rather than a load balancer.
On the Grafana side, the first decision is the configuration database. The default SQLite 3 store does not scale for production, so teams planning high availability need MySQL 8.0 or later or PostgreSQL 12 or later from day one. High availability itself means two or more active-active servers behind a load balancer sharing that database, with database-backed auth tokens. Expect time to go into identity integration (the authentication docs show SAML, team sync, active sync and SCIM are limited to Grafana Enterprise and Grafana Cloud, so confirm whether your identity provider needs those), provisioning files for data sources and dashboards, and the security hardening settings. The documentation also flags two HA issues that often surface late: alerting needs additional configuration to avoid duplicate notifications, and Grafana Live has limitations in HA. Test both with a staging pair before users depend on them.
The slowest part of many projects is rarely the software. Dashboard standards, folder structure, naming and ownership rules, and role-based access control need agreement across the teams that will use them, and those decisions take longer than the configuration. Decide early who may edit shared dashboards, who owns each data source, and whether dashboards live in Git and are loaded through provisioning or edited in the UI, since that choice changes the change-control workflow. Ask any implementation partner to write these standards into the fixed scope as deliverables, and confirm which access controls your Grafana edition provides before scoping.
Questions buyers ask before they hire help
Do we need both Prometheus and Grafana, or can one of them do the job?
Most teams that want dashboards on Prometheus metrics run both, because the two tools do different jobs. Prometheus scrapes metrics over HTTP, stores them in its local time series database and evaluates alerts, while Grafana is a visualization layer that queries Prometheus and many other sources. Prometheus has a built-in expression browser, but it is not meant as a long-term dashboard tool. You can skip Grafana if your team reads PromQL results directly or uses another visualization product that reads Prometheus data. Confirm that any replacement can meet your dashboard, access control and alert-routing needs before you drop it.
Does running Grafana itself cost money?
The Grafana software is licensed under AGPLv3 and can be self-hosted without a license fee, but running it still has costs. Infrastructure, a production database, upgrades, backups and monitoring of the Grafana service itself all carry costs. Grafana's installation docs list SQLite as the default configuration store and say SQLite does not scale for production, so plan for MySQL 8.0 or later or PostgreSQL 12 or later. Grafana Enterprise is a separate commercial option, and the authentication docs say SAML, team sync, active sync and SCIM are available only in Enterprise and Grafana Cloud. Ask any vendor or partner for a written quote that separates one-time setup from recurring hosting and upgrade work.
What does the work need from our own engineers after go-live?
After go-live, someone on your team has to own the Prometheus servers, the Grafana instances, the databases behind Grafana and the alerting path. Prometheus local storage is not clustered or replicated, and the storage docs say it should be managed like any other single-node database, so disk capacity, retention and backups need an owner. Grafana high availability uses two or more active-active servers behind a load balancer with a shared database, and alerting needs extra configuration to avoid duplicate notifications. Dashboards and alert rules are usually kept as code, using Grafana provisioning files, which means someone must review changes and keep them in version control. Ask for a named owner, an on-call path and a runbook for each component before you sign.
Can our team implement Prometheus and Grafana without outside help?
A team with Linux, container and database skills can install both tools alone, and the Grafana installation docs list packages for common distributions, Docker images and Helm charts. The harder part is the production design: scrape configuration across environments, service discovery, Alertmanager clustering, authentication through your identity provider, high availability and a tested recovery path. Teams that lack this experience often find the first months spent on design choices rather than dashboards. If you hire help, most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure.
How long does a Prometheus and Grafana setup usually take, and what drives that?
No supplied source gives a standard duration, so treat any number you hear as unverified until it is tied to a written scope. The main drivers are the number and type of targets, how many environments you connect, whether you need high availability for Grafana and Alertmanager, how much of your identity integration must work at launch, and how many dashboards and alert rules your teams need on day one. Your team's existing familiarity with PromQL and provisioning as code also matters. Ask any provider for a timeline that lists the phases, the systems in each phase and the client decisions that must come first.
Where does long-term metrics storage fit into this design?
Prometheus keeps data in local storage with a default retention of 15 days, which can be set by time or size. If you need longer history, the storage docs describe remote write and remote read protocols that send samples to external long-term storage systems. Grafana can then query that storage as a data source. Long-term storage adds its own component, its own cost and its own failure modes, so decide retention requirements first and choose the storage product later. Related comparisons on this site cover VictoriaMetrics, Thanos and Grafana Mimir as options for that layer. Confirm your retention, data-loss tolerance and query needs in writing before selecting one.
Which Grafana features depend on the license or edition we choose?
Grafana's authentication docs state that all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. Grafana Cloud pricing is published with a free tier, a Pro tier with a stated monthly platform fee plus usage, and an Enterprise tier with a minimum annual commitment. Plugins, SDKs and agent software carry their own licenses, so check each plugin you plan to use. Confirm your identity and audit requirements against the edition before you design the access model.
How DeployOpen helps choose, implement and run the stack
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Prometheus and Grafana decision, we start by settling which layer each tool owns in your environment, then build and hand over only what your team needs to run it.
How we scope
- Written scope fixes which metrics sources, Prometheus servers and Grafana instances are in and out of the engagement.
- We confirm whether Grafana runs as the free OSS build or Grafana Enterprise, since SAML and SCIM depend on that choice.
- Scope names the long-term storage path, retention targets and alert routing to Alertmanager before any build starts.
How we build
- We deploy Prometheus with service discovery or static targets, and document the local storage limits in your environment.
- We configure Grafana with provisioned data sources and dashboards, stored as code and loaded at startup.
- We apply Grafana security hardening settings and set up a PostgreSQL or MySQL backend for any high availability design.
How we hand over
- Deliverables include configuration files, runbooks for scraping, alert routing and backups, and an architecture record.
- We walk your platform and security teams through upgrade paths for each project's release cadence and support windows.
- Testing results and open items are documented so your team can confirm each decision after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
- Retainers can cover version upgrades for Prometheus and Grafana, tracked against the published release and end-of-support dates.
- Any compliance evidence we prepare is for your independent auditors to assess, since DeployOpen does not issue attestations.
