Sizing Grafana servers for users, dashboards and alert rules: where to start
A team moving a shared Grafana from pilot to production usually needs to know how big the server and database should be before anyone builds dashboards at scale. The documented small baseline is under 25 concurrent users on 2 cores and 2 to 4 GB of RAM, and anything beyond that depends on how many people view dashboards at once, how often panels refresh, and how many alert rules the instance evaluates. Those three drivers, not the headcount on the directory, decide whether the baseline still holds. DeployOpen plans and validates sizing inside your own cloud accounts, data centers or air-gapped networks, so the numbers come from your traffic and not from a generic table.
Start by writing down the expected peak of concurrent viewers, the refresh intervals set on the busiest dashboards, and the count of alert rules, including how many run at short evaluation intervals. Then confirm the database choice early, because sizing depends on it. SQLite is the default, but the installation docs state it does not scale for production, so the sizing exercise should assume MySQL 8.0 or later or PostgreSQL 12 or later. Confirm which versions your database platform supports and whether your team will run the database itself or use a managed service, since that changes who owns capacity and backups.
Plan for a load test on a representative copy of your dashboards and data sources before you commit to hardware. Measure CPU and memory on the Grafana server, query latency against your data sources, and database connection use during the peak you expect. The results tell you whether to scale the single server up or to move to two or more active-active instances behind a load balancer, as described in the high availability guide. Ask your partner or internal team to confirm the high availability caveats for alerting and Grafana Live before you choose that path.
What grows load on a Grafana server
Concurrent viewers drive the work Grafana does for each HTTP request: authenticating the session, checking permissions for folders and dashboards, rendering the dashboard model in the browser and returning query results through the backend. Load rises with the number of people active at the same moment, not with the total user count, so a directory of hundreds of accounts may still see a modest peak. Viewer load shows up first as CPU on the Grafana process and as session and permission lookups against the database, which is why the database connection pool matters more as the audience grows.
- Peak concurrency: Ask your identity team for login patterns at shift changes or incident reviews, since those windows set the real peak.
- Session and token lookups: Each active session touches the database, so watch database query time during peaks.
- Permission evaluation: Large folder trees with many permission rules add work on every dashboard load.
- Shared links and embeds: Public or embedded dashboards can attract traffic from outside your normal user base.
- Measure first: Check Grafana's own HTTP request metrics and the process CPU graph against user login times before adding hardware.
Before you change anything, compare peak request rates and CPU during your busiest hour with the number of concurrent sessions you can count from your identity or access logs.
Each panel sends one or more queries to a data source every time it refreshes. The cost of a dashboard is therefore the number of panels, multiplied by the query count per panel, multiplied by how often each panel refreshes and how many viewers keep it open. A dashboard with short refresh intervals over wide time ranges can load a data source far more than the Grafana server itself. Grafana's own CPU and memory increase with the size of query results it must parse, transform and send to the browser, so high-cardinality results are expensive even when the refresh rate is modest.
- Refresh interval: Dashboards left on very short auto-refresh multiply query volume for every open browser tab.
- Time range and resolution: Wide ranges at fine resolution return large series sets that Grafana must hold in memory.
- Panel count and transformations: Many panels and client-side transformations increase per-view CPU and browser work.
- Query caching: Query caching, where enabled, can reduce repeated backend calls, and it changes memory use on the server.
- Measure first: Use the query timing and data source request metrics that Grafana exposes, and find the dashboards that generate the most requests per view.
Before you resize anything, list the top dashboards by request volume and check whether their refresh intervals, time ranges and panel counts are needed for the people who use them.
Alert rules run on a schedule whether or not anyone is looking at a dashboard. Each rule evaluates its queries at its evaluation interval, stores state, and sends notifications when state changes. Load therefore depends on the number of rules, their evaluation interval, the queries each rule runs and the number of alert instances a rule produces, which can be large for rules grouped by label. Alerting writes state to the database on every evaluation, so rule count and interval often load the database more than the viewer count does.
- Rule count: More rules mean more scheduled queries and more state writes per evaluation cycle.
- Evaluation interval: Shorter intervals raise query and database write frequency for every rule in the group.
- Instances per rule: Rules that fan out to many series create many alert instances, each with its own state.
- Query cost inside rules: A rule that scans a wide range on a slow data source can delay the whole evaluation group.
- Measure first: Watch rule evaluation duration and missed evaluations in Grafana's alerting metrics, and compare them with database write latency.
Before adding rules, check evaluation duration against the interval. If evaluations take longer than their interval, the fix is usually fewer or lighter rules, longer intervals where they are acceptable, or a database with more headroom, rather than more viewers' hardware.
Hardware sizing works best when you change one driver at a time and read the results from Grafana's own telemetry. Start from the documented small deployment baseline, then record how CPU, memory, database latency and request duration move as each driver grows. The point where a single node stops meeting its targets is the signal to add capacity, and the signal tells you which resource to add. Without these measurements, teams often scale the Grafana server when the actual limit is database contention or a slow data source.
- Baseline capture: Record CPU, memory, request latency and database query time during a normal week before any change.
- Driver correlation: Compare each metric against concurrent sessions, dashboard requests and rule evaluation counts over the same period.
- Data source latency: Separate time spent waiting on data sources from time spent in Grafana, since the first is not solved by a bigger Grafana server.
- Database signals: Rising connection wait or query time points to the database layer, which is covered in the connection tuning topic.
- Ask your vendor or team: Confirm which metric names and dashboards your Grafana version exposes before you build alerts on them.
Before you buy or resize hardware, confirm which driver is pushing each resource to its limit, because the fix for a database bottleneck is different from the fix for CPU saturation on the Grafana process.
Database and deployment options compared for sizing
This table compares the three database backends Grafana supports and the single-instance and multi-instance layouts that sit on top of them. Read each row against your user count, alert rule volume and availability target to see which sizing consequences apply. The main takeaway is that a production or high availability design requires MySQL or PostgreSQL, so database capacity becomes part of the sizing exercise from the start.
| Option | When it fits | Sizing consequence | What to confirm |
|---|---|---|---|
| SQLite 3 (default) | Evaluation, labs and personal instances with a handful of users | Lowest setup effort, but the Grafana installation docs state SQLite does not scale for production | Whether the instance is genuinely non-production and whether a migration path to MySQL or PostgreSQL is planned |
| MySQL 8.0 or later | Production and high availability where your organization already runs MySQL 8.0 or later | Required for two or more active-active servers; database connection limits and alert rule volume need to be sized together | Supported minor version in your estate, connection limits, and the timeout settings your proxies and load balancers use |
| PostgreSQL 12 or later | Production and high availability where your organization already runs PostgreSQL 12 or later | Required for two or more active-active servers; connection pool size and query load from many users must be sized together | Supported PostgreSQL version, backup and failover approach, and connection limits on the database server |
| Single Grafana instance | Small teams, with the docs sizing small deployments under 25 concurrent users at 2 cores and 2 to 4 GB of RAM | One process carries all viewer, query and alerting load, so headroom must cover peak concurrent users and rule evaluation | Peak concurrent users, dashboard refresh intervals and alert rule count measured in your environment |
| Two or more active-active servers behind a load balancer | Growing user counts or availability requirements that a single node cannot meet | Each node needs CPU and memory for its share of requests, and all nodes share one external database | Load balancer session behavior, alerting configured to avoid duplicate notifications, and the Grafana Live limitations in HA |
| Adding nodes for capacity | Sustained load growth on an existing HA design | Adds request capacity but also adds database connections and cache pressure on shared resources | Whether database contention appears in Grafana metrics before you add another node |
How to size and validate a Grafana deployment
This sequence turns a rough idea of who will use Grafana into a sized, tested deployment and a clear decision on whether one node is enough. Each step ends with a check you can record, so the sizing rests on measurements from your own environment rather than assumptions.
Inventory users, dashboards, data sources and alert rules
Start by counting what the instance must carry: named users and how many will be signed in at the same time, the dashboards they open and how many panels each one contains, the data sources behind those panels, and the alert rules that will evaluate on a schedule. Pull the dashboard and alert rule counts from the existing environment or from the owning teams, and record the refresh interval set on each dashboard. The output is a short inventory sheet. The check is that every dashboard owner has confirmed their peak concurrent viewers and refresh interval, and that the alert rule count is written down with its evaluation interval.
Start from the documented small baseline
Compare the inventory against the small deployment size in the Grafana installation documentation, which describes fewer than 25 concurrent users on 2 cores and 2 to 4 GB of RAM. Use that baseline only as a starting point for a small, lightly loaded instance. If your inventory exceeds it in concurrent viewers, panel count or alert rules, mark the instance as needing measurement rather than assuming it fits. The output is a first-draft host size. The check is that the draft is labeled as a baseline and each factor that pushes it upward is listed next to it.
Choose an external MySQL or PostgreSQL database
Plan the configuration database before load testing. Grafana defaults to SQLite 3, which the installation documentation says does not scale for production, so use MySQL 8.0 or later, or PostgreSQL 12 or later, for anything beyond a throwaway test. Decide where the database runs, who operates it, how its backups are handled, and how many connections the instance will open. Confirm the supported versions against the current installation documentation before you buy or provision anything. The output is a database decision with its version and location recorded. The check is that the Grafana configuration points at the external database and the instance starts and reports the expected database type in its logs.
Load test with representative dashboards and refresh rates
Build a test that resembles real use. Replay the peak concurrent viewer count against dashboards that match the inventory, with the same panel counts, query types, time ranges and refresh intervals, and include the alert rules at their real evaluation interval. Use a load generator your team already runs, and keep the data sources in a state close to production so query latency is realistic. Run the test long enough to see steady state, then repeat it at higher load to find the point where latency or errors rise. The output is a set of CPU, memory and database measurements tied to a load profile. The check is that the test can be rerun with the same profile and produces comparable numbers.
Watch Grafana metrics and database contention
During each test run, watch the server's own metrics for slow requests, failing data source calls, and alert evaluation that falls behind its schedule. Watch the database for long-running queries, lock waits and connection pool saturation, because a sizing problem often shows up there before it shows up in CPU. Enable Grafana's metrics endpoint so these signals are recorded for the whole run, and protect that endpoint as the security documentation recommends. The output is a short report that names the first bottleneck the test reached. The check is that the report identifies whether the limit was the Grafana host, the database, or a data source, and that the same signal can be seen in the metrics on a rerun.
Decide whether to add a second node
Use the test report to decide whether another instance will help. Adding a second node helps when the Grafana process is the bottleneck, and the high availability documentation describes 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. A second node does not help when the database or a data source is the limit, so resolve that first. If you add a node, confirm the alerting configuration to prevent duplicate notifications and review the documented limitations of Grafana Live in highly available setups. The output is a documented decision to stay on one node or to add nodes. The check is that a repeat test with the chosen topology meets the latency and error targets your dashboard owners agreed.
When to add instances behind a load balancer
Adding a second Grafana server is a architectural change, not just more hardware. The triggers below tell you when tuning a single instance has stopped being enough, and each one comes with prerequisites that have to be in place before you add a node.
Sustained pressure after tuning
Before adding nodes, confirm that CPU or memory stays high after you have trimmed dashboards, reduced panel refresh rates and removed unused queries. Check Grafana's own metrics and the host's load over several business days, not during a single spike. If pressure returns on a tuned instance, scaling out is the next step. Ask your partner or vendor to show the measurements that justify it.
Growing concurrent viewers
Concurrent viewers drive request load on the web server and database more than total user count does. Track peak simultaneous sessions during shift changes, incident reviews and executive reporting windows. If those peaks grow faster than you can reduce panel load, a second active node spreads the requests. Confirm the peak with your own usage data before you size the cluster.
Alert evaluation load
Alert rule count and evaluation frequency load the server and the database even when nobody is looking at a dashboard. Growing rule sets can push evaluation delays before the UI feels slow. In a multi-node setup, alerting needs additional configuration so that each notification is sent once rather than by every node. Review that design before you add capacity for rules.
Redundancy requirements
A single Grafana server is a single point of failure for dashboards and alerts. If your operations teams depend on Grafana during incidents, two or more active-active servers behind a load balancer keep access available when one node is down. Redundancy is a separate reason to scale out, and it requires the same prerequisites as capacity growth.
Database prerequisite
Multiple nodes must share a MySQL or PostgreSQL database. SQLite is not suitable for production or high availability, so a database migration is often the first task in a scale-out project. Plan the database version, backups and connection capacity with the migration, not after it. Ask for the database sizing and failover design in writing.
Sessions and Grafana Live
Database-backed auth tokens let users reach any node, so a user is not locked to one server. Grafana Live has documented limitations in highly available setups, so streaming panels may behave differently across nodes. Test WebSocket paths through your load balancer and confirm which live features your users depend on before go-live.
Reducing load before buying more capacity
Dashboard design, refresh intervals, query cost and alert rule count often move load more than hardware does. Before adding cores or memory, review what the instance is being asked to do. A dashboard with many panels, each running a heavy query on a short auto-refresh, multiplies the work for every viewer who keeps it open. Panels that query a data source over long time ranges, or that run unbounded label or log searches, push cost onto the data source and onto Grafana's query path. Alert rules add recurring evaluation work that never stops, so a rule set that grew without review can keep a server busy even when nobody is looking at a dashboard. Ask your team to list the ten most-viewed dashboards and the rules evaluated most often, then check the query interval, time range and panel count of each.
Changes that look small in the UI are easier to control when they are managed as code. Grafana's provisioning docs describe how data sources, dashboards, plugins and alerting resources can be defined in YAML or JSON files loaded at startup, and the same docs point to further as-code options such as Terraform and Git Sync. When a refresh interval, a panel query or an alert threshold lives in a file under version control, the change goes through a pull request, a reviewer can see the query cost it introduces, and a rollback is a revert. Confirm with your platform team which of these resources they plan to provision and which will still be edited by hand, because manual edits to provisioned resources are a common source of drift.
Treat this review as a standing practice rather than a one-time cleanup. Set a rule that new dashboards and alert rules state their expected refresh interval and data source owner, and retire dashboards nobody has opened in a long period. Measure before and after each change using Grafana's own metrics and your data source dashboards, so the decision to add an instance rests on evidence. If load stays high after tuning, that is the point to size hardware or add instances, which the next sections cover.
Security and operational considerations for a sized server
A correctly sized Grafana server still needs its endpoints locked down, its configuration hardened, its data recoverable and its version kept current. The cards below cover the controls that sit alongside capacity decisions, and each one should be checked again whenever the server is resized or a new instance is added.
Require authentication on the metrics endpoint
Grafana exposes a metrics endpoint that reports on the server's own health, and the security hardening guidance recommends requiring authentication for it. Capacity planning depends on these metrics, so the scrape path needs to be protected without breaking the monitoring system that reads them. Confirm which credential your Prometheus scrape job uses and that unauthenticated requests are refused from outside the monitoring network.
Apply the hardening recommendations
The hardening guide recommends secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users and domain verification against DNS rebinding. Apply these settings on every node in the deployment, since a load balancer can route any user to any instance. Review them after each resize, because proxy and TLS changes often reset cookie behavior.
Keep database backups and restores tested
Grafana stores its configuration in SQLite by default, but production and high availability setups need MySQL 8.0 or later or PostgreSQL 12 or later. The database holds the state that a larger instance count and bigger alert rule load make more valuable, so backups must match the database engine you actually run. Schedule a restore test into a separate environment and confirm the instance returns with its dashboards and data sources intact.
Plan upgrades within the release cadence
Grafana's upgrade guidance describes major releases once a year, minor releases every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. Build the upgrade calendar around these windows so that a resized and load-tested deployment does not fall out of support, and read the release notes before each change.
Keep capacity changes under change control
Adding instances, raising database connection limits or changing alert evaluation settings all alter how the system behaves under load. Record each change with the reason, the metric that prompted it and the rollback step, and keep the configuration in version control. Grafana's provisioning files and the Terraform and Git Sync options described in its docs make this practical, because the running state can be compared against a reviewed definition.
Sizing Grafana: questions teams ask before hiring help
What does the baseline Grafana sizing cover, and where does it stop?
The baseline covers a single Grafana server for a small team, and the Grafana installation docs size small deployments at under 25 concurrent users on 2 cores and 2 to 4 GB of RAM. It stops once concurrent viewers, panel refresh rates, alert rule counts or data source query volume exceed that profile. Beyond that point the sizing must be measured in your environment: database load, query latency from your data sources, and alert evaluation time. A baseline is a starting point for a test, not a production answer.
What drives the cost and effort of a Grafana sizing exercise?
Effort rises with the number of data sources, the number of dashboards and panels, how often panels refresh, how many alert rules are evaluated, and how many users are active at the same time. Cost also rises when the exercise must include a load test, a database decision (SQLite is not suitable for production, so MySQL 8.0 or later or PostgreSQL 12 or later is required for production and high availability), or a high availability design with two or more active-active servers behind a load balancer. Ask for each of these as a line item so you can see what changes the price.
How long does a Grafana sizing engagement take?
Duration depends mostly on what you already have. A team with an existing instance, usage metrics and a documented list of data sources can usually provide the inputs quickly, while a team that has to collect usage data, test query latency against each source and agree on refresh targets needs more time. Ask the partner to state the duration in the written scope along with the dependencies it assumes, such as access to the test environment, a representative user count and a window for load testing. DeployOpen agrees timelines in writing before work starts.
What does the work need from our team?
Expect to provide named owners for the Grafana instance and the database, read access to current dashboards and alert rules, a list of data sources with their owners, and typical and peak user numbers from your identity provider or access logs. You will also need a test environment that resembles production, and someone who can approve changes to the database and proxy configuration. Without these inputs, sizing relies on assumptions that often fail under real use.
Can our internal team size Grafana without outside help?
Yes, many teams can do a first sizing themselves if they have Linux and database operations skills and can run repeatable load tests. The work is mostly measurement: track concurrent sessions, query duration, database connections and alert evaluation time, then compare them against the baseline. Outside help is most useful when the instance must support high availability, when alert rules are numerous enough to affect evaluation time, or when the result must be documented for an audit or change board. Check the Grafana high availability guidance on alerting and Grafana Live limitations before committing to a design.
What should a quote for Grafana sizing include?
A quote should state the scope in writing: the Grafana versions and editions covered, the number of data sources, dashboards and alert rules in scope, the target user and refresh profile, and the environments tested. It should list deliverables such as a sizing report, a recommended instance and database specification, a load test plan and results, and a list of assumptions. It should also state what is one-time and what recurs, such as retesting after major upgrades, and what the client must provide. DeployOpen does not publish a price list, so a quote follows from the written scope.
When should we add Grafana instances behind a load balancer?
Add instances when a single server cannot meet your availability target or when measured load on one node, such as CPU, memory or slow dashboard loads, stays high at peak. High availability requires two or more active-active servers behind a load balancer sharing a MySQL or PostgreSQL database, with database-backed auth tokens so users can reach any node. Plan alerting for high availability separately, because the docs note extra configuration is needed to avoid duplicate notifications, and Grafana Live has limitations in that setup.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Grafana inside your own cloud accounts, data centers or air-gapped networks. For sizing, we start from the users, dashboards, data sources and alert rules you expect to run, then turn that into a written capacity plan, a tested deployment and a handover your team can operate.
How we scope
- Written scope lists expected concurrent viewers, dashboard count, panel refresh intervals and alert rule volume for your Grafana.
- Scope names the target database, either MySQL 8.0 or later or PostgreSQL 12 or later, and states whether high availability is required.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before sizing work begins.
How we build
- We build a load test plan that simulates viewer concurrency, refresh rates and alert evaluation against a staging instance.
- We measure CPU, memory and database connection use, then record which thresholds trigger a second instance behind your load balancer.
- We configure provisioning files and infrastructure definitions so the sized configuration can be reproduced without manual edits.
How we hand over
- You receive a capacity document with the tested baseline, the growth drivers we measured and the trigger points for scaling out.
- We document the resource settings, database choice and load balancer configuration, with the reasoning behind each value.
- Your team gets a walkthrough of the Grafana metrics to watch and the signals that show the instance needs more capacity.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, including re-sizing after new dashboards or alert rules are added.
- Retainer work can repeat load tests after Grafana minor and patch releases, which arrive at least monthly according to Grafana's upgrade guidance.
- We review capacity against growth in users and alert rules, and recommend changes in writing before anything is altered in production.
