Why a production Grafana needs PostgreSQL or MySQL as its database
If your team is moving Grafana off its default SQLite file because SQLite does not scale for production or high availability, the answer is to move the configuration store to PostgreSQL 12 or later, or MySQL 8.0 or later. Those are the minimum versions Grafana supports for this role, and the Grafana installation docs state that MySQL or PostgreSQL is required for production and for any high availability design. SQLite stays suitable only for a single-node evaluation instance.
The Grafana database holds the state that makes an instance a Grafana instance: data source definitions, dashboards and folders, users, teams, organizations, preferences, and the sessions and auth tokens that keep people signed in. Alerting state and other operational records also live there. Grafana writes this state at runtime through the UI and API, so it is not a file you can copy into place once and forget. Confirm the exact tables your Grafana version writes with the current installation and high availability documentation before you size storage or plan maintenance windows.
The database is also the shared state behind every Grafana node. In a high availability layout, two or more active-active servers sit behind a load balancer and read the same database, which is why a user can reach any node and keep their session. That design moves risk into the database: its availability, connection capacity, TLS configuration and backups now determine whether Grafana can serve anyone. Decide early who owns that database, which minimum version you will standardize on, and how you will verify backups before you point the first production node at it.
PostgreSQL or MySQL: how to choose the Grafana database engine
The strongest predictor of a stable Grafana database is whether your team already operates one of the two engines well. Backups, restores, patching, user management, monitoring and incident response all carry over from your existing platform, so a familiar engine usually costs less to run than a new one, even if the other engine has features you like. Grafana only stores its configuration, dashboards, users and alerting state here, but that state is still business critical and must be recoverable.
- Existing platform: If you already run PostgreSQL or MySQL for other services, use the same engine unless a specific requirement points elsewhere.
- Backup tooling: Confirm your existing backup and restore tooling covers the Grafana database schema and a tested restore path.
- On-call coverage: Check that people on call can diagnose connection and locking problems on the chosen engine.
- Configuration standards: Reuse your organization's TLS, password policy and network controls for the Grafana database role.
- Vendor support model: Decide who you will call when the engine fails, whether that is your internal team, a cloud provider or a support contract.
Before you choose, ask your database team which engine they can run at 2 a.m. without outside help, and confirm that answer against your current runbooks.
Both engines are open source, but their licenses and commercial editions differ in ways that matter for procurement. PostgreSQL uses a permissive license, while MySQL Community Edition uses the GPL and is paired with a commercial Enterprise Edition. Check your legal team's requirements for embedding, redistribution and paid support before you decide, since Grafana itself is licensed under AGPLv3 and the database license does not change that.
- PostgreSQL License: A liberal license similar to the BSD or MIT licenses, with no commercial edition required to run the server.
- MySQL Community Edition: Freely downloadable under the GPL, with replication, InnoDB Cluster, Group Replication and MySQL Router included.
- MySQL Enterprise Edition: Adds Enterprise Backup for hot backups, Transparent Data Encryption, Enterprise Audit, Enterprise Firewall, external authentication modules and 24x7 Oracle support.
- Support contracts: Commercial support is available for both engines from several vendors. Ask for a quote based on your written scope.
- Feature gaps: If you need hot backups or encryption at rest from the vendor, confirm whether your chosen edition provides them.
Have legal review the license terms for your deployment model before the database is procured.
Grafana's high availability setup needs a shared database, but the database itself needs its own high availability design. Both engines offer replication and clustering, yet neither makes failover fully automatic by default. Plan the failover tool, the quorum model and the connection path before the build starts, so Grafana nodes do not depend on a single database address.
- PostgreSQL: Streaming replication with hot standbys is built in, but detecting a primary failure and promoting a standby requires external tools such as Patroni, or a Kubernetes operator such as CloudNativePG.
- MySQL Community: InnoDB Cluster and Group Replication include automated failover, with MySQL Router and MySQL Shell for connection routing and administration.
- Synchronous or asynchronous replication: Decide how much data loss is acceptable on failover, since synchronous replication waits for standbys before a commit completes.
- Failover testing: Schedule failover tests in a non-production environment and record how Grafana nodes reconnect.
- Connection routing: Confirm how Grafana finds the writable node after a switchover.
Confirm with your team which failover tool you will run and who owns it before selecting the engine, because the tooling shapes the day-two workload more than the initial install does.
The engine you choose must be on a version that still receives vendor security fixes for the life of the deployment. Grafana's minimums are MySQL 8.0 or later and PostgreSQL 12 or later, but a version can meet that minimum and still be out of support. Check the support end dates against your planned upgrade cycle, not only against the day you install.
- PostgreSQL support window: PostgreSQL ships a major version about once a year and supports each for five years. Versions 14 through 18 are listed as supported, with 14 ending November 12, 2026 and 18 ending November 14, 2030.
- PostgreSQL minimum for Grafana: Version 12 is the minimum Grafana supports, but it is no longer under PostgreSQL vendor support, so do not deploy it for new work.
- MySQL LTS track: MySQL 8.4 LTS and 9.7 LTS follow the Oracle Lifetime Support Policy, while Innovation releases are supported only until the next Innovation release.
- MySQL 8.0: It is the minimum Grafana supports, so confirm its current Oracle support status before choosing it.
- Upgrade planning: Schedule database major upgrades alongside Grafana upgrades, and confirm each engine's supported Grafana combination in the vendor documentation.
Before you commit, check the current support end date for the exact version you plan to run and set a reminder well ahead of it.
Database configuration options and when each fits
This table compares the database choices you make when pointing Grafana at PostgreSQL or MySQL, including engine version, TLS, connection limits, replication and pooling. Read each row against your own uptime target and team skills, then confirm the matching settings in the Grafana configuration reference before you commit.
| Option | When it fits | Trade-off |
|---|---|---|
| Engine: PostgreSQL 12 or later | Your team already runs PostgreSQL and wants one database platform for Grafana and other internal tools | Grafana's minimum is version 12, but upstream support for 12 and 13 has ended, so choose a supported major such as 17 or 18 for new builds |
| Engine: MySQL 8.0 or later | Your standard is MySQL, or you need Group Replication or InnoDB Cluster from the same vendor family | Version 8.0 is the Grafana minimum, while the 8.4 LTS track gives a longer support window; confirm the version you pick is supported at install time |
| TLS mode and certificate verification | Any database reached over a network you do not fully control, or any compliance scope that expects encryption in transit | Stronger verification needs a CA bundle distributed to every Grafana node and a rotation process; confirm the TLS mode names in the Grafana configuration reference |
| Connection pool limits | Several Grafana replicas share one database, so total connections across nodes must stay below the database limit | Too few connections queue requests and slow dashboards; too many exhaust the server; set limits per node and confirm the defaults in the Grafana configuration reference |
| Connection lifetime | Failover or load balancers close idle sessions, so Grafana should recycle connections before the network drops them | Short lifetimes add reconnect overhead; long lifetimes can keep sessions pointing at a former primary after a failover |
| Asynchronous replication | Read scaling or a warm standby for recovery, and you accept that the latest committed changes can be lost on failover | Lower write latency, but a failover may roll back recent Grafana changes such as new dashboards or alert rule edits |
| Synchronous replication | Configuration changes must survive a primary failure, and your team can accept slower commits | Every commit waits for a standby, so a slow or unreachable standby slows the whole Grafana instance |
| Connection pooler such as PgBouncer | Many Grafana replicas or other clients open many short connections to PostgreSQL | Adds a component to patch, monitor and make highly available; check session-level behavior with Grafana before you rely on it |
| Direct connection without a pooler | A single Grafana node or a small number of replicas with a clear connection budget | Simpler to operate, but connection counts grow with each added node and can outrun the database limit |
How to set up the Grafana database step by step
This sequence takes a Grafana instance from its default SQLite file to a PostgreSQL or MySQL database that is encrypted in transit, pooled sensibly, and shared by at least two nodes. Each step ends with a check you can run before moving on.
Confirm supported database and Grafana versions
Before provisioning anything, confirm that your target database is inside its support window. Grafana's installation docs require MySQL 8.0 or later or PostgreSQL 12 or later for production, and the PostgreSQL versioning policy lists 14 as the oldest version still supported at the time of writing, with support ending November 12, 2026. Check the MySQL Community Server download page for the current LTS and Innovation tracks. Record the database version and the Grafana version you plan to run. Done means you have written both down and confirmed the database version appears on the vendor's supported list.
Provision the database and a least-privilege Grafana user
A database administrator creates an empty database for Grafana and a dedicated login that owns only that database. Do not reuse the superuser or root account, and do not grant the Grafana user rights on other databases. Restrict the host or network range the login may connect from. Verification: sign in with the new account using the psql or mysql client, confirm you can create and drop a test table inside the Grafana database, and confirm you cannot read another application's database.
Enable TLS on the database server
Your database team installs a server certificate issued by the internal CA or a trusted public CA, and enables TLS on the server. Confirm the client certificate chain and the hostname that Grafana will use. Verification: from the Grafana host, run a connection with TLS required and check that the session reports an encrypted connection. A failed handshake here usually means a hostname mismatch or an untrusted CA, so fix it at the server or the trust store before continuing.
Set the database section in grafana.ini
Edit the [database] section of grafana.ini, or set the equivalent GF_DATABASE_ environment variables, to choose type, host, name, user and password, and the TLS mode that matches your server certificate. Store the password through a secret mechanism rather than plain text in the file. Verification: restart nothing yet, but run a configuration check against the file and confirm the values resolve to the intended host and database. Keep this file under version control so the change can be reviewed.
Set connection limits and connection lifetime
Set the maximum open connections, maximum idle connections and connection lifetime in the [database] section so that Grafana cannot exhaust the server when several nodes start at once. Size the total across all Grafana nodes against the database's own connection limit, and leave headroom for administrators and other applications. Ask your database team for the current max_connections value. Verification: after startup, count open sessions from the Grafana user on the server and confirm the total stays under the limit you set.
Start Grafana and confirm schema migration
Start the Grafana service on the first node and watch its logs. On first start against an empty database, Grafana creates its schema, so the logs should show migrations running without errors. Verification: confirm the server reports healthy on its health endpoint, that the database contains Grafana tables, and that you can sign in to the web interface with the admin account. If migrations fail, correct the permissions or TLS setting, then restart; do not hand-edit the schema.
Test a second Grafana node against the same database
Start a second Grafana node pointed at the same database, behind the load balancer you plan to use. Both nodes must read the same configuration and sessions. Verification: sign in on node A, then load the session on node B without signing in again, and confirm that a dashboard saved on one node appears on the other. Grafana's high availability docs note that alerting needs extra configuration to avoid duplicate notifications, so treat alerting as a separate check before production.
Record the configuration and confirm backups run
Document the database version, TLS mode, connection settings, and the Grafana user's privileges in your runbook. Confirm with your database team that a scheduled backup covers the Grafana database and that a restore has been tested on a separate server. Verification: a restore of the Grafana database to a scratch instance starts Grafana and shows existing dashboards. The sequence is complete when this restore test passes.
How database high availability works for Grafana
Grafana high availability depends on a shared database, so the database has to be redundant before you add a second Grafana server. The Grafana HA guidance describes two or more active-active Grafana servers behind a load balancer, all reading and writing the same MySQL or PostgreSQL database. If that database has a single node, the Grafana tier is redundant in name only. Plan the database cluster first, then size the Grafana nodes against it.
On the PostgreSQL side, a hot standby can serve read-only queries while it waits to take over, but Grafana's configuration writes still go to the primary. The main decision is replication mode. With synchronous replication, a commit waits for at least one standby, which protects committed dashboards and alert state at the cost of write latency and of stalls when standbys are slow or unreachable. Asynchronous replication keeps writes fast but can lose the most recent commits during a failover. Test both modes against your write rate and recovery point objective. PostgreSQL does not detect a failed primary or promote a standby by itself, so you need an external tool such as Patroni or CloudNativePG on Kubernetes to manage failover and to keep Grafana pointed at the new primary.
MySQL offers a built-in path. MySQL Community Edition includes Group Replication with automated failover, and InnoDB Cluster packages it with MySQL Router and MySQL Shell. Router is the component that sends Grafana connections to a usable member, so confirm that your Grafana connection string and the Router setup match the failover behavior you have tested. Whichever database you choose, two Grafana limits persist in HA. Alerting needs extra configuration so that several nodes do not send duplicate notifications, and Grafana Live has limitations in HA, so do not assume live streaming behaves the same on every node. Confirm both against the current HA documentation for your Grafana version before go-live.
Security controls for the Grafana database connection
The Grafana database holds users, dashboards, data source definitions and encrypted secrets, so the connection needs the same care as the database itself. The four controls below work together: encrypt and verify the connection, limit who can reach the database, limit what each account can do, and keep credentials out of configuration files. Check each one against your own environment before go-live.
Verified TLS on the database connection
Grafana connects to PostgreSQL or MySQL over the network, so the session needs TLS with certificate verification, not just encryption. In Grafana's database settings, choose a ssl_mode that verifies the server certificate and provide the CA certificate that signed it. Confirm the chosen mode in your own environment, because modes that skip verification encrypt traffic without proving the server is the database you expect.
Least-privilege database accounts
Create a dedicated database and role for Grafana that owns only its own schema. Do not reuse the database superuser, a shared application account or an administrator account. Grafana runs its own schema migrations at startup, so confirm with your DBA whether the account needs DDL rights during upgrades, and remove those rights afterward if your change process allows it.
Network restriction to Grafana nodes
Allow inbound connections to the database port only from the addresses of your Grafana servers or containers, and from the administrative hosts that need them. Place the database on a private subnet with no route from user networks. If you run Grafana in Kubernetes, express the same rule as a network policy. Review the rule whenever you add a Grafana replica or change node addresses.
SCRAM password authentication for PostgreSQL
Set PostgreSQL password authentication to SCRAM-SHA-256 and avoid MD5 for the Grafana role. PostgreSQL 18 deprecates MD5 password authentication in favor of SCRAM, so older pg_hba.conf entries that rely on MD5 should be replaced during the database build. Confirm that your PostgreSQL version and client driver support the method before you change the rule for the Grafana role.
Credential handling and encrypted audit options
Keep the database password out of grafana.ini and version control. Pass it through a file-based secret mounted at runtime, using the __FILE suffix convention where your Grafana packaging supports it. For audit and encryption at rest, the MySQL Enterprise Edition adds Transparent Data Encryption and Enterprise Audit. Community Edition does not include these features, so confirm which edition you run and plan equivalent controls such as disk encryption and database logs otherwise.
Backups, point-in-time recovery and planned database upgrades
Backups for Grafana have to cover the Grafana database itself, because dashboards, data sources, users, folders and alerting configuration live there rather than in the container or package files. A backup that has never been restored is an assumption, so schedule a restore test into a separate instance on a regular basis and time how long it takes to bring Grafana back up against the restored database. For PostgreSQL, the PostgreSQL continuous archiving documentation describes base backups combined with archived WAL segments, which allow point-in-time recovery to a moment just before an accidental change. Decide the recovery point you need before choosing the tooling, and confirm with your database team how archive storage is protected and retained.
For MySQL, confirm which backup method fits your recovery target before you rely on it. Logical dumps are simple to run and verify, but they are not a substitute for a tested restore plan. Hot backups for MySQL are part of MySQL Enterprise Backup, which is a commercial edition feature, so if your design depends on hot backups without downtime, confirm the licensing and edition with your vendor and budget for it as a recurring cost. Community tooling can cover logical backups and binary log retention, but confirm the exact procedure and recovery steps with your own database administrators before going live.
Plan PostgreSQL upgrades in two tracks. Minor updates replace executables and restart the server, and they never change the internal storage format, so they are the routine patch path. Major upgrades need a deliberate method: pg_upgrade, a dump and restore, or logical replication, which the upgrade documentation says can limit downtime to several seconds. Tie these plans to Grafana's release cadence: Grafana patch releases come at least monthly, and each minor release is supported for 9 months, so check the supported PostgreSQL range against the Grafana version you intend to run before the next major upgrade window. Rehearse the chosen method on a copy of production data, and record the database version in your change calendar.
Questions teams ask before configuring the Grafana database
Can we keep SQLite as the Grafana database for a small team?
For a small team, SQLite can run a lab or a low-stakes instance, but it is not the choice for production. The Grafana installation docs state that SQLite does not scale for production, and that MySQL or PostgreSQL is required for production and high availability. The default install stores configuration in SQLite 3, so moving later means exporting and importing state, which is work you will pay for once. If you expect more than a handful of users, more than one Grafana server, or alerting that must survive a restart, plan for MySQL 8.0 or later, or PostgreSQL 12 or later, from the start. Confirm the current minimum versions in the Grafana installation docs before you choose.
What does a Grafana database setup cost, and what drives the price?
Cost has three parts: the work to build the database and connect Grafana, the infrastructure that hosts it, and the ongoing operation. The build effort depends on whether you are standing up a new database or migrating an existing SQLite instance, how many Grafana servers connect, which TLS mode your security team requires, and whether high availability and tested backups are in scope. Infrastructure cost depends on your cloud or data center pricing, which you already know better than any vendor. Recurring work includes patching, minor and major version upgrades, backup restore tests and capacity reviews. Ask any partner for a fixed-scope quote with those items listed separately, so one-time build work and recurring operations are visible.
How long does it take to configure a production Grafana database?
Duration depends on scope rather than on a standard number of days, so treat any single figure you read as unverified for your environment. The main drivers are whether a new database cluster must be provisioned, whether an existing SQLite or older database must be migrated, the number of environments (development, test and production), and whether high availability, connection pooling and point-in-time recovery are included. Before work starts, the reader should provide the target database engine and version, network paths from Grafana servers, a TLS requirement, backup retention and restore objectives, credentials handling, and a change window for the cutover. A written scope with a timeline is the right document to ask for.
Can our internal DBA team configure the Grafana database on its own?
Often yes, if the team already runs MySQL or PostgreSQL in production. The Grafana side is a matter of creating a dedicated database and user, setting the database type, host, credentials and TLS options in the Grafana configuration, and verifying connections. The harder parts are usually outside the Grafana configuration: high availability of the database itself, connection limits and lifetime tuned for several Grafana nodes, backup and restore tests, and upgrades on a fixed schedule. For PostgreSQL, automatic failover needs external tools, because PostgreSQL does not detect a primary failure on its own. Ask your DBA team to confirm who owns each of these items after go-live, since that ownership decides whether the setup stays healthy.
Is PostgreSQL or MySQL cheaper to run for Grafana?
Neither engine is cheaper by default, and licensing does not usually decide the question for Grafana. PostgreSQL is released under the PostgreSQL License, a liberal open source license similar to BSD or MIT. MySQL Community Edition is available under the GPL. Most of the running cost comes from high availability design, backup storage, staff skills and upgrade effort. MySQL Community Edition includes InnoDB Cluster and Group Replication with automated failover, while PostgreSQL high availability usually relies on tools such as Patroni or CloudNativePG. Enterprise features such as hot backups or Transparent Data Encryption belong to MySQL Enterprise Edition, which carries a commercial cost. Choose the engine your team already operates well, then compare the operational tooling each one requires.
What do we need to provide to an outside partner for this work?
A partner can only write a fixed-scope quote when you provide the facts that shape the design. Bring the target Grafana version and deployment method (container, virtual machine or Kubernetes), the database engine and version you have approved, the number of Grafana servers and expected concurrent users, your network segmentation and any restricted egress rules, the TLS mode and certificate authority, backup and retention requirements, and the change window for cutover. You should also name the people who approve access, the existing monitoring for the database, and the rollback plan you accept. DeployOpen plans, implements and documents these systems inside your own infrastructure, so the environment details stay with you.
Which database engine versions should we target for Grafana in production?
Target versions that the database vendor still supports and that Grafana supports at the same time. Grafana requires MySQL 8.0 or later, or PostgreSQL 12 or later, as minimums. PostgreSQL 12 is no longer a sensible target because the supported versions listed in the PostgreSQL versioning policy are 14 through 18, and PostgreSQL 14 support ends on November 12, 2026. MySQL 8.0 is listed on the MySQL Community Server download page, while 8.4 is an LTS track. Check the current support dates in the PostgreSQL versioning policy and confirm the Grafana minimum in the Grafana installation docs before you lock the version.
How DeployOpen scopes and delivers Grafana database setup
DeployOpen treats the Grafana database as a planned part of the platform, not a default setting. We agree the database engine, TLS mode, connection limits, high availability and backup approach in writing, then build and verify them in the infrastructure you control. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Written scope names the chosen engine, PostgreSQL 12 or later or MySQL 8.0 or later, and the reasons for that choice
- Scope records TLS mode, certificate sources and which Grafana instances connect to the database
- Scope sets out who owns database high availability, failover tooling and backup retention, and where that boundary sits
How we build
- We configure Grafana database settings and connection limits and lifetime against your planned instance count
- We set up database high availability and backups in your environment, then test restore and failover paths
- We document each configuration key, its value and its owner so changes can be reviewed before rollout
How we hand over
- Handover includes a runbook covering restarts, failover steps, backup restore and database upgrade stops
- Configuration is delivered as files kept in your version control, so the database setup can be reviewed and reproduced
- We walk your operators through the verification results and the open items that remain with your team
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Support can cover database minor and major version planning against the published PostgreSQL and MySQL support timelines
- We recommend confirming any changes to the database layout with your own change control before applying them
