docs/sources/setup-grafana/installation/_index.md
This page lists the minimum hardware and software requirements to install Grafana.
To run Grafana, you must have a supported operating system, hardware that meets or exceeds minimum requirements, a supported database, and a supported browser.
The following video guides you through the steps and common commands for installing Grafana on various operating systems as described in this document.
{{< youtube id="f-x_p2lvz8s" >}}
Grafana relies on other open source software to operate. For a list of open source software that Grafana uses, refer to package.json.
Grafana supports the following operating systems:
{{< admonition type="note" >}} Installation of Grafana on other operating systems is possible, but is not recommended or supported. {{< /admonition >}}
Grafana requires the following minimum system resources:
Some features might require more memory or CPUs. For more information, refer to the following sizing guidance.
This sizing guidance covers the Grafana server process only, meaning the UI, data source proxy, alert engine, and image renderer. It does not account for the resources required by your data sources. Metric stores such as Prometheus or Grafana Mimir, log stores such as Grafana Loki, and trace backends such as Grafana Tempo each have their own hardware and capacity requirements. For guidance, refer to Planning Grafana Mimir capacity, Size the Loki cluster, and Plan your Tempo deployment.
Four factors most directly drive resource needs for Grafana:
Image rendering and large numbers of short-interval alert rules are the two most common reasons a deployment outgrows its initial sizing. Multi-organization setups and SSO or LDAP directory sync add overhead that can push a deployment into the next tier.
Use the table below to identify which tier describes your workload, then refer to the corresponding hardware baseline.
| Tier | Concurrent users | Alert rules | Data sources | Dashboards |
|---|---|---|---|---|
| Small | < 25 | < 100 | < 5 | < 200 |
| Medium | 25 – 200 | 100 – 1,000 | 5 – 25 | 200 – 2,000 |
| Large | 200+ | 1,000+ | 25+ | 2,000+ |
The dashboard count threshold assumes roughly 10-20 panels per dashboard with refresh intervals of 30 seconds or longer. Dashboards with more panels or shorter refresh intervals produce proportionally more query load and should be weighted toward the higher tier. Similarly, the data source count assumes a mix of source types. Deployments that rely heavily on proxied SQL sources should plan for the next tier up.
These thresholds are starting points. Validate sizing with a load test that reflects your actual dashboard complexity, panel count, and refresh rates before committing to production hardware. Size for your current workload and include headroom for traffic spikes and growth.
Small deployments suit small teams, internal tooling, and low-traffic environments.
| Resource | Minimum |
|---|---|
| CPU | 2 cores |
| Memory | 2 – 4 GB |
| Disk | 10 – 20 GB SSD (database host) |
| Instances | 1 |
Database: SQLite works for local development and small evaluation instances, but isn't recommended for production environments. For production use, consider an external MySQL or PostgreSQL instance for higher reliability and growth capacity. For more information, refer to Supported databases.
Image rendering: optional; can run on the same host for light use. Refer to Set up image rendering.
Medium deployments suit shared team environments and departmental observability platforms.
| Resource | Recommendation |
|---|---|
| CPU | 4 – 8 cores |
| Memory | 8 – 16 GB |
| Disk | 20 – 50 GB SSD (database host) |
| Instances | 2 (load-balanced) |
Database: SQLite isn't recommended for production environments and isn't suitable at this tier. Use an external MySQL or PostgreSQL database. Refer to Supported databases for guidance on choosing an external database.
Image rendering: run the image renderer as a separate process or container. Each renderer worker uses approximately 1 GB of memory; size your renderer host accordingly. Refer to Set up image rendering.
High availability: if you run two or more Grafana instances, configure a Redis session store or enable sticky sessions at the load balancer to prevent users from being signed out between requests. Refer to Set up Grafana for high availability.
Large deployments suit organization-wide platforms and high-traffic production environments.
| Resource | Recommendation |
|---|---|
| CPU | 8 – 16+ cores per instance |
| Memory | 16 – 32+ GB per instance |
| Disk | 50+ GB SSD, high I/O operations per second (IOPS) (database host) |
| Instances | 3+ (load-balanced) |
| Network | 10 Gbps or faster |
Database: SQLite isn't recommended for production environments and isn't suitable at this tier. A highly available MySQL or PostgreSQL cluster is strongly advised. Refer to Supported databases.
Image rendering: run a dedicated renderer fleet with multiple workers, isolated from Grafana instances. Each renderer worker uses approximately 1 GB of memory. Refer to Set up image rendering.
Alert evaluation: with more than 1,000 alert rules or short evaluation intervals of under one minute, alert evaluation can saturate CPU and degrade dashboard query performance on the same instance. Isolate alert evaluation to one or more dedicated Grafana instances in remote evaluation mode to prevent this. Refer to Performance considerations and limitations.
High availability: sticky sessions or a shared Redis session store are required. Refer to Set up Grafana for high availability.
Data source latency: minimize network hops between Grafana instances and data sources. Low-latency links to your database and data sources are important at this scale.
Deployment model: managing three or more Grafana instances alongside a Redis cluster, renderer fleet, and highly available database becomes operationally complex on bare metal. Kubernetes reduces this operational burden significantly at this tier. Refer to Deploy Grafana on Kubernetes and the Grafana Helm chart for guidance.
Grafana requires a database to store its configuration data, such as users, data sources, and dashboards. The exact requirements depend on the size of the Grafana installation and the features you use.
Grafana supports the following databases:
By default Grafana uses an embedded SQLite database, which is stored in the Grafana installation location. If you need to migrate to a different database later, note that database schema and data migrations are customer-managed operations and fall outside the scope of Grafana Support.
{{< admonition type="caution" >}}
SQLite isn't recommended for production environments. It works well for local development and small evaluation instances, but it doesn't scale for production workloads. If you want high availability, you must use either a MySQL or PostgreSQL database. For information about how to define the database configuration parameters inside the grafana.ini file, refer to [database].
{{< /admonition >}}
Grafana supports the versions of these databases that are officially supported by the project at the time a version of Grafana is released. When a Grafana version becomes unsupported, Grafana Labs might also drop support for that database version. See the links above for the support policies for each project.
{{< admonition type="note" >}} PostgreSQL versions 10.9, 11.4, and 12-beta2 are affected by a bug (tracked by the PostgreSQL project as bug #15865) which prevents those versions from being used with Grafana. The bug has been fixed in more recent versions of PostgreSQL. {{< /admonition >}}
{{< admonition type="note" >}} Grafana binaries and images might not work with unsupported databases, even if they claim to be drop-in or replicate the API to their best. Binaries and images built with BoringCrypto may have different problems than other distributions of Grafana. {{< /admonition >}}
Grafana can report errors when relying on read-only MySQL servers, such as in high-availability failover scenarios or serverless AWS Aurora MySQL. This is a known issue; for more information, see issue #13399.
Grafana supports the current version of the following browsers. Older versions of these browsers might not be supported, so you should always upgrade to the latest browser version when using Grafana.
{{< admonition type="note" >}} Enable JavaScript in your browser. Running Grafana without JavaScript enabled in the browser is not supported. {{< /admonition >}}
{{< qa-list >}} {{< qa question="What operating systems does Grafana support?" >}} Grafana supports Debian and Ubuntu, RHEL and Fedora, SUSE and openSUSE, macOS, and Windows. You can also run Grafana in a container with Docker or deploy it on Kubernetes with the Grafana Helm chart. Installing Grafana on other operating systems is possible but is neither recommended nor supported. For platform-specific steps, refer to the installation guide for your operating system. {{< /qa >}} {{< qa question="What are the hardware recommendations to run Grafana?" >}} At a minimum, Grafana needs 512 MB of memory and 1 CPU core, but that's a floor for evaluation rather than a production target. Actual requirements are driven by four factors: concurrent users, the number of alert rules and how often they evaluate, the number and type of data sources, and your panel count and dashboard refresh intervals. The documentation groups workloads into Small, Medium, and Large tiers with a hardware baseline for each. For example, a small deployment starts at 2 cores and 2–4 GB of memory, while a large deployment runs multiple load-balanced instances at 8–16+ cores and 16–32+ GB of memory each. This guidance covers the Grafana server process only. It doesn't account for your data sources, because metric, log, and trace backends such as Grafana Mimir, Grafana Loki, and Grafana Tempo have their own capacity requirements. Treat the tiers as starting points and validate them with a load test that reflects your real dashboards before you commit to production hardware. For more information, refer to Sizing your deployment. {{< /qa >}} {{< qa question="What resources do I need to run Grafana?" >}} To run Grafana, you need four things:
Beyond that, plan for the components that scale with your workload:
Remember that your data sources are sized separately from Grafana itself. {{< /qa >}} {{< qa question="What databases does Grafana support?" >}} Grafana stores its own configuration data — users, data sources, dashboards, and so on — in a database, and supports the following:
New installations use an embedded SQLite database by default, stored in the Grafana installation directory. SQLite works well for local development and small evaluation instances but isn't recommended for production, and high availability requires MySQL or PostgreSQL. Grafana supports the database versions that are officially supported upstream at the time a given Grafana version is released, so support for a database version might be dropped when the corresponding Grafana version goes out of support. Migrating between databases is a customer-managed operation that falls outside the scope of Grafana Support, so choose your backend before you scale up. This is separate from the data sources that Grafana queries for visualization, which are covered in the data sources documentation. {{< /qa >}} {{< /qa-list >}}