Why moving Grafana from SQLite to PostgreSQL or MySQL is a planning task, not a file copy
Your Grafana instance is running on the default SQLite file, and now it needs to serve production users or run highly available. The database move is usually contained, but verification and alert state take most of the care. Grafana stores its configuration in SQLite 3 by default, and the Grafana installation docs state that SQLite does not scale for production. For production and high availability, Grafana requires MySQL 8.0 or later or PostgreSQL 12 or later, so the target database is a decision you need to make before any data moves.
The work is more than pointing Grafana at a new connection string. Dashboards, folders, data source definitions, users, teams, API keys and service accounts, and preferences all live in the database, and so does alert state. Your plan should name who owns the target database, where it runs, how it is backed up, and which Grafana version will read the migrated data. Confirm with your own team whether provisioned resources in files will override database content on restart, since that changes what you need to compare afterward. Also confirm the Grafana version you are running now, because the upgrade guidance sets the supported version window you should land on.
Verification is where most of the risk sits. Before cutover, agree on a set of checks: object counts for dashboards, folders, data sources and users; spot checks of dashboards that depend on specific data sources; a test of login and permissions for each identity method in use; and a review of alert rules, contact points and silences against the source instance. Alert state is the hardest item to confirm, because a missing or duplicated notification is only visible when an alert fires. Plan to run the old and new instances side by side for a defined period, and record the rollback path before you start.
What carries over from SQLite and what needs rework
This table compares each item held in Grafana's default SQLite file with how it is handled after a move to PostgreSQL or MySQL. Read it as a checklist: the database rows usually move with a migration, while file paths, plugins, provisioning, sessions and secrets need a separate check in your environment.
| Item | On PostgreSQL or MySQL | What to confirm or rework |
|---|---|---|
| Dashboards and folders | Stored in the database, so they move with the data export and import when the schema is recreated | Confirm dashboard counts and folder trees match after cutover, and check any dashboards that reference local file paths |
| Data sources | Definitions are stored in the database and migrate with it | Check that credentials are still readable, since encryption keys in the config file must match the new instance |
| Users, teams and org roles | Stored in the database and carried over by a full database migration | Confirm login works for every identity provider, and check team membership against your directory |
| API keys or service accounts and tokens | Stored in the database, so they are expected to carry over | Test a sample of scripts and CI jobs, and confirm token expiry settings are unchanged |
| Preferences, annotations and playlists | Stored in the database and generally carried over | Spot-check annotations on key dashboards, since they reference time ranges and dashboard IDs |
| Alert rules and alert state | Rules are stored in the database; alert state is runtime data and may reset | Confirm rule counts, contact points and notification policies, and expect active firing state to be recalculated |
| Sessions and login state | Session storage depends on configuration, so existing sessions may end at cutover | Plan for users to sign in again and confirm the session settings in the new configuration file |
| Plugin settings and installed plugins | Plugin settings records move with the database, but plugin files live on disk | Reinstall or confirm plugin files on each node, and verify plugin versions are compatible with the target release |
| Provisioning directories and file-based configuration | Not stored in the database, so they stay on the file system of each server or container | Confirm provisioned data sources and dashboards load from the same paths on every node, and keep them in version control |
| Secrets, signing keys and database connection settings | Encryption keys, secret keys and the database connection live in the configuration, not the database | Store the same secret key values on every node, and verify encrypted data source secrets decrypt after migration |
How to choose between PostgreSQL and MySQL for Grafana
Grafana documents both MySQL and PostgreSQL as production database backends, so the choice rests on your organization's operating standards rather than on Grafana itself. The cards below cover the version floors, release tracks, licensing, skills and high availability tooling that should drive the decision before any dashboards or alert state move.
Supported engine versions
Grafana requires MySQL 8.0 or later or PostgreSQL 12 or later for the external database. Check that the engine version you plan to run is on that list and still receives vendor security fixes on the date you expect to go live. A version that meets Grafana's floor but is close to end of support will force a second database upgrade soon after the migration, so plan both changes together.
Release and support tracks
PostgreSQL ships one major version a year and supports each for five years, so teams schedule major upgrades on a steady cadence. MySQL offers an LTS track with long support windows and an Innovation track that is supported only until the next Innovation release. Choose the track your team can keep current, and confirm the end-of-life date for the exact version with the vendor before you commit.
Licensing terms
PostgreSQL uses the PostgreSQL License, a permissive license similar to BSD or MIT. MySQL Community Edition is available under the GPL. Legal and procurement teams should review both licenses against their redistribution and internal-use policies, especially if the database will be bundled into images or appliances that you ship to others. Grafana's own AGPLv3 license is a separate question that applies regardless of the database you choose.
Existing operations skill
The engine your database administrators already run well is usually the lower-risk choice. Ask who will handle backups, point-in-time recovery, patching, failover testing and query troubleshooting after go-live, and whether those people have run the engine in production before. If your team has no experience with either engine, the cost of learning one during a migration should be part of the quote and the internal plan.
High availability tooling
Grafana high availability needs two or more active-active servers sharing one external database. PostgreSQL provides hot standbys and synchronous or asynchronous replication, but automatic failover needs an external tool. MySQL Community Edition includes InnoDB Cluster and Group Replication with automated failover, along with MySQL Router and MySQL Shell. Compare the failover mechanism, the team that will operate it and the recovery testing you can sustain.
Standards and documented fit
Both engines are documented for Grafana, so neither choice is a compromise in functionality. The deciding question is which engine already has approved images, backup tooling, monitoring, access controls and an on-call runbook in your organization. Write that down as the selection criterion, then confirm with Grafana which engine version and configuration your chosen setup targets before the migration plan is finalized.
Which migration path fits a small, shared or HA Grafana
A single small instance is the simplest case. It has one Grafana server, a modest number of dashboards and users, and a maintenance window the owners can accept. Because all state sits in one SQLite file, the team can stop Grafana, copy the data, and start it against the new database. Configuration kept in files is the easiest part to carry across, since provisioning files load at startup.
- Stop writes first: Stop the Grafana service so no dashboard edits or alert state changes happen during the copy.
- Keep the original file: Back up the SQLite file and the configuration directory so you can restore the previous state if the move fails.
- Point the new database: Set the
[database]section of the configuration file to the new MySQL or PostgreSQL server, and confirm in the installation docs how the schema is created for your version. - Reapply provisioned resources: Keep data sources and alerting resources in provisioning files so they reload when the new server starts.
- Check the result: Sign in, compare folder and dashboard counts, and send a test notification from one alert rule.
Confirm the exact export and import steps for your installed version before the window, because the documented method and related tooling can change between releases. The installation docs list the package and container options your version supports.
A shared instance usually holds many teams' folders, dashboards, data sources and users, so the copy matters more and the cutover affects more people. The database move itself follows the same basic steps as a single instance, but rehearsal and post-cutover review take longer. Some state is easy to recreate from files, while local users, sign-in sessions and tokens exist only in the database, so each needs its own check.
- Rehearse on a copy: Restore a copy of the database to the target engine, start a test instance, and compare dashboards, folders and users before the production window.
- Keep configuration in files: Store dashboards and data sources in provisioning files or Git-managed resources where possible, so configuration can be reapplied if the database copy has gaps.
- Map identity: Determine whether users sign in through an external provider or through local accounts, since local accounts live in the database.
- Plan for sign-in resets: Expect some users to sign in again, and check API tokens and service accounts after the move.
- Review alert state: Confirm rules and contact points loaded, and that each notification is sent once.
Before the window, compare folder, dashboard and user counts between the source and the restored copy, and confirm the steps for your version with the upgrade and installation documentation.
Moving straight into two or more active-active servers changes the target more than the data. Grafana's high availability setup has every node share one MySQL or PostgreSQL database behind a load balancer, so the database becomes the single source of truth from the first start. Users may reach any node, which means the migration must finish before traffic reaches the cluster, and everything stored outside the database must match across nodes.
- One shared database: All nodes read the same MySQL or PostgreSQL database, and the original SQLite file serves only as a rollback copy.
- Initialize one node first: Let a single node create the schema and load data, verify it, and only then add the other nodes.
- Configure alerting for HA: The docs note that alerting needs additional configuration to avoid duplicate notifications, so set this before routing alert traffic.
- Keep node files identical: Provisioning files, plugins and other file-based assets must match on every node.
- Test live features: Grafana Live has limitations in HA, so test any dependent feature and confirm how the load balancer handles sessions.
Run the rehearsal with the load balancer, the sign-in flow and one alert notification in place, and check the high availability setup page for your version before routing users to the cluster.
Documented tools and paths for exporting and importing Grafana data
Grafana does not ship a single migration command for moving its state between databases. The practical work splits into copying the database itself, pointing the server at the new engine, and re-applying dashboards and data sources as code or through the API. Each path covers a different part of the state, so the plan needs all of them.
Copying the database with native tools
The database-native tools do the bulk copy. On the PostgreSQL side, pg_dump and restore move schema and rows; on the MySQL side, mysqldump plays the same role. Load the copy into an empty database created for Grafana, then compare table row counts and a sample of dashboard and user records before you point Grafana at it. Confirm with the vendor how your Grafana version expects the schema to be created, because a hand-built schema can differ from the one Grafana migrates on first start.
Configuration keys that switch the engine
The [database] section of grafana.ini, or the matching GF_DATABASE_* environment variables in container deployments, selects the engine, host, name, user and password. Stop Grafana before you change these keys, start it once against the empty target, and check the logs for migration errors. Confirm the exact key names and any SSL options against the installation docs for your version before you change production.
Provisioning files for data sources and dashboards
Provisioning loads data sources, dashboards, plugins and alerting resources from YAML or JSON files at startup. If your dashboards and data sources already live in provisioning directories, a new database can be populated from those files without exporting anything from the old server. Dashboards created in the UI but never exported are the usual gap, so inventory them first.
HTTP API for dashboards and data sources
The HTTP API can read dashboard JSON and data source definitions from the old instance and write them to the new one. This suits small instances and selective moves, and it works across instances that are not on the same database. Scripted exports need a service account token with the right scope, and secrets stored in data sources are not returned in readable form, so plan to re-enter those credentials manually.
State that needs manual handling
Some state does not survive a plain copy or an export. Alert state and evaluation history, active user sessions and login tokens, and encrypted secrets depend on the server's secret key and the database contents together. Plan to let sessions expire or force sign-in again, re-check alert rules and contact points after cutover, and confirm the handling of encrypted values with the vendor for your version.
Verifying the move against each path
Each export path needs its own check before cutover. Compare counts of dashboards, folders, users, teams, data sources and alert rules between the old and new instances, open a sample of dashboards that use each data source, and confirm that scheduled alerts evaluate on the new database. Record the Grafana version and the check results so the next upgrade can repeat the same tests against a known baseline.
The sequence for moving Grafana with a parallel run and cutover
This sequence moves a self-hosted Grafana from its default SQLite file to MySQL or PostgreSQL while proving that dashboards, users, alert state and data source access survived the move. The result is a tested cutover with a retained rollback path.
Inventory dashboards, users, alert rules and plugins
Before touching the database, the Grafana administrator and the team that owns each dashboard export what the instance holds: folders and dashboards, users and teams, Grafana-managed alert rules and contact points, data sources with their connection settings, and installed plugins with their versions. Provisioned resources are noted separately because they reload from files at startup and do not need to be migrated as database rows. Secrets such as data source passwords are recorded as locations, not copied into the inventory. The step is done when every object type has a count and an owner, and the list is stored with the change record so the later comparison has a baseline.
Build the target database with controlled access
The team creates the target database on MySQL 8.0 or later, or PostgreSQL 12 or later, using the version policy of the database vendor and the support windows for that release. A dedicated database and role are created for Grafana with only the privileges it needs, the connection is encrypted, and the database server is reachable only from the Grafana nodes. Backups are configured and a first restore test is scheduled before any data moves. The step is done when the empty database accepts a test connection from the Grafana host, the backup job has produced a restorable copy, and the credentials are stored in the team's secrets manager rather than in a plain configuration file.
Pilot the move into a test instance
The team takes a fresh copy of the SQLite file and a backup of the current configuration, then starts a separate test Grafana pointed at the new database and migrates the copy. Grafana creates its schema on first start, so the pilot shows whether the database version, the database user privileges and the Grafana version work together. The test instance is checked for login, dashboard rendering, data source queries and whether alert rules load and evaluate. Any object that fails is logged with its type and cause. The step is done when the pilot runs cleanly, the failures are understood and the configuration changes needed for production are written down.
Run both instances in parallel and compare
The production instance keeps running on SQLite while a second instance runs on the new database against the same data sources. The team compares object counts from the inventory, spot-checks key dashboards for panel errors, confirms that users sign in through the same identity provider, and reviews the alert state. Alert rules must be evaluated by only one instance at a time, because two evaluators send duplicate notifications, so the parallel instance has alerting paused or its contact points muted. The step is done when counts match, the spot-check list passes with the owners' sign-off, and the differences are either fixed or accepted in writing.
Plan and execute the cutover window
The team fixes a cutover window with the owners of dashboards and on-call staff, freezes changes to dashboards and alert rules on the source instance, and takes a final SQLite backup immediately before switching. The load balancer or DNS record is moved to the new instance, the old instance is stopped from evaluating alerts, and the new instance is started with alerting enabled. The on-call team checks that a known test alert fires once and reaches the expected contact point. The step is done when users reach the new instance, the alert test passes, and the cutover record shows the time of the freeze, the final backup and the switch.
Verify after cutover and keep the rollback path
After cutover, the team repeats the inventory and spot-check tests on the live instance and watches for failed logins, data source errors and duplicate or missing notifications. Rollback remains possible while the SQLite file and the final backup are kept unchanged and the old instance is stopped rather than deleted. The team agrees with the owners how long the rollback path stays open and what triggers a rollback. The step is done when the post-cutover checks match the baseline and the owners confirm their dashboards and alerts work.
Decommission SQLite with a retained backup
Once the owners have confirmed the new instance, the old SQLite file is removed from the running host and archived with its configuration and the final backup, under the same retention and access rules used for other production records. The Grafana configuration is updated so no environment still points at the SQLite file, and the backup jobs for the new database are confirmed to run. The step is done when the archive is verified as readable, the old file is no longer used by any process, and the decommissioning record names who approved it and where the archive is stored.
What drives the cost and duration of the move
This table lists the factors that most change the effort of moving Grafana off SQLite, whether each one is paid once or recurs, and what to request in a written quote. Use it to see which parts of your instance are large or unusual, then ask a partner to price each driver explicitly.
| Driver | Why it changes effort | One-time or recurring | What to request in a quote |
|---|---|---|---|
| Dashboards and folders | Each dashboard, folder and nested permission must be exported, moved and checked, so counts drive verification time. | One-time | Inventory counts by organization and folder, plus the verification method for each. |
| Organizations and users | Multiple organizations mean more scoping, and user, team and role mappings must survive the move intact. | One-time | Mapping approach for users, teams, roles and org IDs, and who signs off on access. |
| Data sources and their types | Each data source needs connection details, secrets and provisioning checks, and unusual types may need extra testing. | One-time | List of data sources by type, with the credential handling plan for each. |
| Plugins and Angular dependencies | Dashboards using AngularJS plugins may need migration or replacement before the database work is safe to finish. | One-time, possibly recurring if plugins are kept | Plugin inventory, Angular usage findings and the plan for third-party plugins. |
| Legacy alerting and alert state | Legacy alert rules, notification channels and alert state need separate conversion and testing, and duplicate notifications must be prevented during cutover. | One-time | Alert rule count, legacy channel types, and the cutover and rollback test plan. |
| Provisioning maturity | Instances managed by files or as-code tools can be rebuilt faster, while hand-edited instances need full exports and reconciliation. | One-time, with lasting savings if as-code is adopted | Current provisioning coverage, and whether the target will be managed as code afterward. |
| High availability requirements | Two or more active-active nodes, shared sessions, alerting deduplication and load balancer changes add design and test work. | One-time for design and test, recurring for database and node operations | Node count, load balancer approach, and how alerting duplicates will be prevented. |
| Database platform and operations | MySQL or PostgreSQL must be sized, secured, backed up and patched by your team, which adds recurring operating work. | Recurring | Who operates the database after handover, backup retention, and the version support plan. |
| Backup and restore testing | A verified restore of the SQLite file and the new database is the basis for proving nothing was lost, and it must be repeated for each rehearsal. | One-time per rehearsal, plus recurring restore tests | Number of rehearsals, restore test scope, and the evidence delivered at each step. |
| Change windows and cutover | Limited maintenance windows, rollback requirements and user communication shape how many rehearsals are needed. | One-time | Available windows, rollback criteria and who approves go or no-go decisions. |
What usually goes wrong when Grafana leaves SQLite
Moving Grafana off SQLite is simple to start and easy to get subtly wrong. The risks below cluster around three moments: the database switch itself, the move into high availability, and the restore or cutover that follows, and each one has a check you can run before users notice.
Duplicate alert notifications in HA
Once two or more active Grafana servers share one database, each node can evaluate alert rules and send notifications. The Grafana HA docs state that alerting needs additional configuration to avoid duplicate notifications, so teams often discover this from repeated pages. Test alert routing on a staging pair with a known rule before any production cutover, and confirm each notification fires once.
Lost or duplicated alert state
Alert instance state and silences live in the database, so an export that skips them or a restore into a partly populated target can leave alerts firing twice or resetting to normal. Compare alert rule counts and silence lists between the source and target before switching traffic. Plan a short window where the old instance is paused so the state is not written in two places.
Logins broken by changed settings
Users sign in through sessions and auth tokens that depend on cookie and root URL settings. When a new database, domain or proxy path changes those values, users may be signed out or redirected to a broken callback. Record the current root_url and cookie settings, carry them into the new configuration, and test a full login through your identity provider from a clean browser.
Secret and encryption key mismatches
Data source passwords and other stored secrets are encrypted with a key held in the Grafana configuration. If the target instance uses a different secret key, the migrated data sources load but cannot connect, which looks like a network fault. Copy the secret key exactly, verify it in the target configuration, and test each data source connection before declaring the move complete.
Grafana Live limits in HA
Live streaming features, such as live dashboard updates, have limitations when Grafana runs as several active servers. Teams that move to HA expecting identical real-time behavior can be surprised by panels that update late or only on some nodes. Confirm which Live features your dashboards depend on, and tell users which views refresh on a timer instead.
Missing plugins and incomplete restores
Plugins installed on the old server are not carried over by a database copy alone, and a dashboard that loads without its panel plugin shows errors only when someone opens it. Also, a database dump without the plugin directory, provisioning files or image renderer setup restores only part of the instance. Inventory installed plugins, store provisioning files in version control, and restore into a test instance before retiring the source.
How to verify that dashboards, users and alert state survived
Record an inventory of the SQLite instance before anything moves. Capture counts and names for dashboards, folders, users, teams, data sources and alert rules, and export them in a form you can diff later, such as API listings saved to files with a timestamp. Include the provisioned objects too, because provisioning files loaded at startup may recreate data sources and dashboards on the new database and can make a count look right when the underlying state is wrong. Also note which alert rules are paused and which contact points and notification policies exist, since those are the parts most likely to change silently. Ask your team to agree on this inventory as the sign-off baseline before the cutover window opens.
After the restore, compare the new instance against that baseline item by item rather than trusting totals. Check that a sample of dashboards opens with the same panels and data source references, that folder permissions still match, and that teams hold the same members. Then test sign-in through your identity provider with a representative set of accounts, including an administrator, a viewer and a user who belongs to a synced team, because authentication settings and external user mappings are a common source of loss. Confirm that existing sessions behave as you expect after the move. Record each result in the same document as the baseline so the evidence can go to your auditors without reconstruction.
In a high availability design, verify alerting as a behavior, not only as data. Confirm that rules evaluate on schedule, that a test alert reaches each contact point exactly once, and that only one node is sending notifications, since the Grafana high availability documentation says alerting needs additional configuration to avoid duplicate notifications. Keep the SQLite file, its backups and the original configuration untouched until every check passes and a full evaluation cycle has completed on the new database, then retire it in a separate, recorded change. Confirm with your own tests the exact rollback steps for your Grafana version, because the decision to keep the old file depends on them.
Questions teams ask before moving Grafana off SQLite
What drives the cost of moving Grafana off SQLite?
The cost depends on how much work sits around the database change: the size and state of the existing instance, how many dashboards, data sources, users and alert rules must be checked, whether the database target is new or already run by an operator, and how many environments (test, staging, production) need the same procedure. Some costs are one-time, such as planning, the migration rehearsal, cutover and verification. Others recur if you add a database operator, backups, monitoring and patching for the new database. Ask any partner for a fixed-scope quote that lists each environment, the database engine and version, the backup and rollback method, the verification checks, and who handles the database side. Grafana documents supported backends as SQLite 3, MySQL 8.0 or later, and PostgreSQL 12 or later, so confirm which engine and version your team will run before pricing starts.
How long does the move usually take?
No supplied figure sets a standard duration, so the timeline is driven by factors you can measure. These include the number of instances and environments, the volume of dashboards, users and alert state to verify, how much of the Grafana configuration is already provisioned as code, the availability of a database operator and a change window, and whether the target database already exists. A minimal instance with few users moves faster than one with many teams, custom plugins or integrations that touch the database. Ask for a timeline in the written scope that separates preparation, rehearsal on a copy, the production change window and post-cutover verification, and that names the dependencies on your side.
What does our team need to provide for the migration?
Plan to provide several inputs before work starts. An inventory of the current instance covers its version, the grafana.ini settings, installed plugins, data sources, provisioning files and any external integrations that read from the SQLite file. You will also need administrative access to the host and the Grafana UI, a non-production copy for rehearsal, a change window agreed with the business owners of dashboards and alerts, and named database operators who can create the target database, roles, network rules, backups and monitoring. Procurement and security teams should confirm how credentials and connection strings are stored. Ask the partner to list these inputs in the quote so gaps show up before the change window.
Can our own team do the migration without a partner?
Yes, if your team has the skills and time to run it. Grafana publishes installation and configuration documentation, and the work is a sequence of known steps: back up the SQLite file, prepare the target database, point Grafana at it, and verify the result. The risk is in the details, such as confirming the target engine version, checking that the database backups and restores work, testing alert behavior after the change, and proving that dashboards, users and alert state match the source. A partner adds value when your team lacks database or Grafana operations experience, needs an independent rehearsal, or must meet a compliance deadline. Whichever path you choose, rehearse on a copy first and keep the SQLite file until verification passes.
Is high availability required if we move to MySQL or PostgreSQL?
Not for every instance, but production and high availability need an external database. Grafana's installation documentation says SQLite does not scale for production, and its high availability design uses two or more active-active Grafana servers behind a load balancer that share a MySQL or PostgreSQL database with database-backed auth tokens. Moving the database is the first step. Running several Grafana servers also requires configuration for alerting so notifications are not duplicated, and the documentation notes that Grafana Live has limitations in HA. Confirm how your team wants to handle failover for the database itself. PostgreSQL does not include software to detect a primary failure and promote a standby, so automatic failover requires external tools.
Do alert rules and alert state move cleanly?
Alert rules and their configuration are stored in the database, so they move with it when the migration copies the data correctly. Alert state, such as pending or firing instances and silences, needs explicit verification after cutover. Do not assume it survived. Before the change window, record the list of alert rules, contact points, notification policies and silences, and their current states. After cutover, compare them and watch for duplicate or missing notifications, especially if you run more than one Grafana server. Any alert channel that depends on a local file or a plugin should be tested separately. Ask for this comparison to be part of the written acceptance criteria.
What happens to users' sessions during the cutover?
Session and login state is stored in the Grafana database, so the cutover usually signs users out or forces a fresh login, depending on the method used. The exact behavior depends on your Grafana version and how you authenticate, so confirm it in a rehearsal. Plan a communication to users about a possible sign-in prompt, check that single sign-on callbacks and root URL settings still match after the change, and verify that API tokens and service accounts still work for scripts and CI. Note that the exact token and session handling should be checked against the Grafana version you run, because the authentication docs describe database-backed tokens for high availability setups.
What should we verify before and after the cutover?
Verify with counts and samples, not just a successful startup. Before cutover, record the number of organizations, folders, dashboards, data sources, users, teams, service accounts and alert rules in the source instance. After cutover, compare the same counts, open a sample of dashboards per team, run queries against each data source, confirm user logins and permissions, and check that alert rules evaluate and notifications arrive at test contact points. Keep the SQLite file and a tested backup until the acceptance checks pass and the business owners sign off. Ask the partner to document these checks and the rollback steps in the written scope.
Official Grafana and database documentation to read first
Before you change anything, read the Grafana installation documentation and the high availability guide. The installation page confirms which database engines Grafana supports for configuration storage and states that SQLite does not scale for production, so MySQL or PostgreSQL is required for production and high availability. The Grafana high availability documentation explains the two-or-more active-active server model behind a load balancer, database-backed auth tokens, and the extra alerting configuration needed to avoid duplicate notifications. Use both to decide whether your target is a single externalized server or a clustered setup, because that choice changes how you sequence the cutover.
Next, read the Grafana provisioning documentation. If your data sources, dashboards or alerting resources are already defined in files or managed as code, you can rebuild them on the new database instead of copying rows, which lowers the risk of carrying stale state across. Then check the Grafana upgrade guidance on when to upgrade against the Grafana minor version you run today, since database migrations run on startup and the required steps differ by release. Confirm the exact Grafana version you will target in the release notes before the first test run.
Finally, read the PostgreSQL and MySQL pages that match your chosen engine. For PostgreSQL, the upgrading a PostgreSQL cluster guide and the versioning policy show which major versions are still supported on the date you plan to go live, and the supported-version list in the policy is the place to confirm end-of-life dates. For MySQL, the MySQL releases reference explains the LTS and Innovation tracks. Check which Grafana release notes name the minimum database version you must run, and record that version in your change plan.
How DeployOpen scopes, delivers and supports the Grafana database move
DeployOpen plans and carries out the move of a self-hosted Grafana instance from its default SQLite file to MySQL or PostgreSQL, inside infrastructure you control. The work starts with a written scope that names the dashboards, users, data sources and alert state in play, and ends with documented checks showing what moved and what was verified.
How we scope
- We confirm your installed Grafana version and target database engine before any change is planned.
- The written scope lists dashboards, folders, users, teams, data sources, alert rules and notification settings in the move.
- We document the environments covered, including production, staging and any high availability nodes you plan to run.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We build the target database and connection settings in a staging copy of your instance first.
- Migration steps are run against a recent copy of the SQLite data, with each step recorded for repeatability.
- We check dashboards, users and alert state against a before-and-after inventory before cutover is approved.
- Configuration is captured as code where possible so the target setup can be reviewed and rebuilt.
How we hand over
- You receive a runbook covering the cutover sequence, rollback steps and the post-move verification checks.
- Verification evidence, including inventory comparisons and test results, is delivered with the project record.
- Our team walks your operators through the new database connection, backups and monitoring before handover.
- Open items and the decisions made on your behalf are listed so your team knows what was deliberately left out.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the move.
- A retainer can cover later Grafana upgrades, database version planning and periodic restore tests.
- Support scope and response arrangements are set out in writing, so you know what the retainer includes.
- Questions about a quote should be answered with the written scope, which drives the effort and cost.
