Grafana database connection tuning

Connection pool settings and when each one fits

This table compares the connection pool settings a team adjusts on Grafana's database connection, with the risk at each extreme and the load pattern that calls for a change. Read each row against your own user count, alert rule volume and database limits. The main takeaway is that raising pool sizes without checking the database's connection ceiling usually moves the bottleneck rather than removing it.

How MySQL and PostgreSQL change the tuning work

How to set and verify the pool on a running Grafana

This sequence moves a running Grafana from its current connection settings to tuned pool and lifetime values, one node at a time, with a check after each change. The result is a documented baseline, a verified configuration and evidence that alert evaluation and query latency hold under load.

1. Record current database limits and timeouts

   Before changing anything, the database owner and the Grafana administrator record the server's maximum connection setting, the idle and wait timeouts configured on the database server, any connection proxy or pooler in front of it, and the current pool values in the Grafana configuration file on each node. Confirm the values with the database administrator instead of relying on defaults, because the MySQL or PostgreSQL limit must comfortably exceed the total of all Grafana nodes multiplied by the open connections per node. Done when the values sit in a change record that the team can compare against later checks.

2. Measure the baseline connection count and waits

   Capture the number of connections Grafana holds to the database on each node, along with the database's own view of active sessions, waiting queries and lock waits during a typical business window and during alert evaluation peaks. Grafana's own metrics endpoint can show request latency and database-related errors, which helps link slow dashboards to database contention. Done when the team has a baseline table of connections per node and wait signals per time window, so later changes have something to be measured against.

3. Set pool and lifetime values on one node

   On a single Grafana node, the administrator sets the maximum open connections, maximum idle connections and connection lifetime in the database section of the configuration file, choosing the lifetime to end before any idle or wait timeout enforced by the database server or a proxy in between. Keep the change in version-controlled configuration and apply it through the same change control used for other production configuration, with a documented rollback to the recorded values. Done when the file change is reviewed, approved and committed.

4. Restart the pilot node and check connections

   The administrator restarts only the pilot node during an approved window and confirms it starts cleanly. Within the same window, the team checks that the node's connection count stays under the configured maximum and that idle connections are being released rather than accumulating. Done when the connection count on the pilot node matches the new limits and the database shows no new waiting sessions attributable to Grafana.

5. Check logs and alert evaluation on the pilot

   The team reviews the Grafana server logs on the pilot node for database timeout, connection refused or too many connections errors, and confirms that alert rule evaluations continue to run on their scheduled intervals in the alerting views. Errors such as connection reset or closed by the server suggest the lifetime is longer than a timeout somewhere in the path, so the lifetime should be lowered before continuing. Done when the logs show no timeout errors over the observation period and alert evaluations complete on schedule.

6. Run a representative load test before rollout

   Before applying the change to the remaining nodes, the team runs a load test that mirrors real usage, including concurrent dashboard viewers, scheduled panel refreshes and the full set of alert rules. Compare query latency, error rates and database waits against the baseline recorded earlier. Done when latency stays stable at the agreed targets and the database shows no growing queue of waiting connections during the test.

7. Roll the configuration to the remaining nodes

   The administrator applies the same reviewed configuration to each remaining node one at a time, restarting each node and repeating the connection, log and alert evaluation checks before moving on. Keep the previous values available so any node can be reverted. Done when every node reports connections within the configured limits, no node logs timeout errors, and the combined connection total stays within the database limit recorded in the first step.

8. Record the final state and schedule a review

   The team saves the final pool values, baseline and post-change measurements, load test results and the change record in the same repository or ticket system used for other production changes. They also schedule a recurring review of connection counts and database waits, especially after adding dashboards, alert rules or Grafana nodes. Done when the change is closed in change control with the evidence attached and the review date is assigned to a named owner.

Spotting database contention in Grafana's own metrics

Failure modes that appear when the pool is wrong

Connection pool problems rarely show up as a clear database error. They appear as dashboards that hang, alerts that arrive late or twice, and sessions that drop for no visible reason. Each card below names the first symptom a team sees and the setting or check that usually explains it.

Security and operational points for database connections

Limits to confirm in your environment before changing the pool

The right pool size depends on limits that sit outside Grafana: what the database server allows, who else uses it, and how traffic reaches Grafana. Confirm these before you change any setting, because a larger pool only helps when the database and the proxies in front of it can accept the extra connections.

Common questions about tuning Grafana database connections