What upgrades and support involve for Metabase
Staying current is the core of supporting a self-hosted Metabase, and the version plan decides how much work that takes. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life about 2 months after release. Every release receives bug fixes and security updates until its end-of-life date, so an instance that drifts onto a non-LTS line or waits too long between LTS releases will soon run without patches. Before go-live, agree which line you will follow, who checks the version support page, and how far behind the team is willing to run.
Several events should start upgrade work: an approaching end-of-life date for your running version, a security release that affects your deployment, an instance several versions behind the current release, or no named owner after go-live. Each upgrade runs application database migrations automatically on startup. Confirm before you schedule anything that the application database is backed up first, that you know which version last wrote to it, and that you have a tested path back if the migration fails.
Routine minor upgrades within a release line are often within reach of an in-house operator who tracks Metabase releases and follows the upgrade steps in the documentation. Major upgrades, multi-release catch-up from versions older than 40, and clustered instances that must be reduced to a single node for the migration lock are usually better handled with a partner. The partner's work centers on a rehearsed backup and rollback, release-by-release sequencing and retained support after the change.
What the work includes
Each work package below is written into the agreed scope, so you know what is included before any work starts.
Version assessment and upgrade plan
We check your current Metabase version against the version support page to confirm whether it is LTS or non-LTS and when it reaches end of life. Non-LTS releases usually reach end of life after 2 months, so an older install may already be unsupported. Versions older than 40 need stepwise upgrades, release by release. The output is a written upgrade plan with target version and sequence.
Backup and restore verification
Metabase runs application database migrations automatically at startup, so we back up the application database before any upgrade step. We then restore that backup into a separate environment and confirm Metabase starts against it. Confirm your database engine, PostgreSQL or MySQL, along with backup location and retention before work starts. A backup that has never been restored is unproven.
Staging rehearsal and single-node runbook
We rehearse the upgrade on a copy of your production setup in staging before touching production. Major upgrades require reducing a cluster to one node because of the migration lock, so the runbook sets out which node stays, the order for removing the others and how they rejoin. Load balancer changes and the downtime window are agreed in advance and recorded in the runbook.
Rollback procedure
Rollback restores the pre-upgrade application database backup, which the Metabase docs recommend, or runs the migrate down command with the newer JAR. We document which path applies to your version pair, the exact JAR and configuration to redeploy, and the point after which a clean rollback is no longer possible. Agree in advance who can authorize rollback during the window.
Post-upgrade validation
Validation checks what users and processes depend on: SSO sign-in and group mapping, each data source connection, scheduled jobs and embedded dashboards and questions. Each check has a named owner and a recorded result in the validation checklist. Confirm your SSO protocol and plan tier first, since SSO and embedding features differ by edition.
Handover and support terms
Handover leaves your team a runbook covering upgrade steps, backup locations and rollback. Ongoing support can be a retainer covering release monitoring and planned upgrades. The deliverables you keep are the upgrade plan, runbook, backup and restore records, validation checklist and support terms, all agreed in a written scope before work starts.
What drives cost and effort
This table lists the factors that change the size of a Metabase upgrade or support engagement and the practical steps that keep each one manageable.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Distance from starting version | Upgrades from versions older than 40 run release by release, so each step adds testing and a separate upgrade cycle. | Confirm your current version early and agree the upgrade path in writing before scheduling work. |
| Application database engine | Embedded H2 usually means a migration to PostgreSQL, MySQL or MariaDB first, which adds a load-from-h2 step and checks. | Move to PostgreSQL before the upgrade so the upgrade runs on the production database engine. |
| Cluster size | Major upgrades require reducing the cluster to a single node because of the migration lock, which adds planning and temporary capacity changes. | Document the cluster topology and the steps to scale down and back up before the window opens. |
| Number and type of data source connections | Each connected database can behave differently after a version change, so each one needs a query and dashboard check. | List every connection, its owner and the questions that depend on it, and test the highest-use sources first. |
| Custom SQL, API scripts and embedded content | Native questions, scripts calling the REST API and embedded dashboards must be retested because they may break after an upgrade. | Inventory these assets and tag the critical ones so retesting focuses on what the business relies on. |
| Edition and authentication setup | SSO configured on Pro or Enterprise, or LDAP and Google sign-in on other plans, must be verified after each upgrade. | Record the identity provider settings and test sign-in with a test group before and after the change. |
| Number of environments | Each environment such as test, staging and production needs its own upgrade run, backup and sign-off. | Keep environments as close in version and configuration as practical so one tested procedure applies to all of them. |
| Compliance evidence requirements | Assessors may ask for records of change approval, backups, test results and rollback readiness for each upgrade. | Confirm the evidence list with your assessor and build the upgrade runbook to produce it. |
| Agreed maintenance window | A short, fixed window limits the number of checks and the room for rollback, so the scope must fit the time available. | Agree the window, rollback decision point and communication plan in the written scope before the upgrade starts. |
How the upgrade project runs
The five phases move a Metabase instance from a version plan and tested backup to a single-node upgrade, a documented rollback decision and a handover that keeps the instance on a supported version.
Inventory the version and plan the target
Record the running version, database type and instance count. Choose a target LTS or release, and confirm its end-of-life date on the Metabase version support page. LTS versions are supported for 14 months, while non-LTS versions usually end after 2 months. If you run a version older than 40, the plan lists each release to pass through. Output: a written version plan approved by the client.
Back up and rehearse on a copy
Take a backup of the application database and confirm it can be restored, since the docs recommend this before any upgrade. Restore the backup to a separate environment and run the upgrade there first, checking that migrations complete and dashboards load. Output: a tested backup and a rehearsal log showing the exact steps and any issues to fix before the change window.
Run the single-node major upgrade
Reduce a clustered deployment to one node, because the docs call for a single node during major upgrades due to the migration lock. Stop the service, replace the JAR or container image with the target version, and start Metabase so it runs its application database migrations automatically. Output: one node running the target version, with migrations logged as complete, before other nodes are added back.
Validate and decide on rollback
Check sign-in, a sample of saved questions and dashboards, scheduled emails and data source connections against the criteria agreed in the plan. Restore the pre-upgrade backup if data or permissions are wrong, which is the documented recommendation. Running migrate down with the newer JAR is an option only when your team has confirmed it in the rehearsal. Output: a signed rollback decision recorded in the change log.
Hand over and set up ongoing support
Hand over the upgraded instance with the version record, backup locations, rollback notes and runbook for the next upgrade. Agree on how new LTS and non-LTS releases will be tracked, and who approves each upgrade, since non-LTS versions have short support windows. Ongoing support can be a retainer, which DeployOpen offers. Output: a handover pack and a named support contact agreed in writing.
What goes wrong and how to prevent it
Each card names a failure specific to Metabase upgrades, the step that prevents it, and the check that confirms the step worked.
Clustered upgrade hits the migration lock
Several Metabase instances sharing one application database must be reduced to a single node before a major upgrade, because the migration step takes a lock that blocks the other nodes. Check the upgrade runbook for the exact sequence, then confirm that only one node serves traffic and that the remaining nodes are stopped before the migration starts.
Untested backups and migrate down rollback
Migrations run automatically at startup, so the application database must be backed up before the new JAR starts. Rollback should restore that backup, which the Metabase docs recommend, and the team should prove the restore on a copy. Running migrate down with the newer JAR is a fallback, so rehearse it before relying on it.
Skipping steps from older versions
Metabase recommends upgrading release by release when starting from a version older than 40, so the application database migrations run in order. Jumping straight to the latest release from an older install can leave migrations untested. Check the installed version first, list each intermediate release, and confirm the instance starts cleanly after each step.
End-of-life drift goes unnoticed
Non-LTS releases usually reach end of life about two months after release, and LTS releases are supported for 14 months, so an instance can slip out of support unnoticed. Record the running version, its end-of-life date from the version support page, and a named owner. Check that the inventory is reviewed on a set schedule and that upcoming end-of-life dates are on the team calendar.
SSO, embedding and scheduled delivery break
Sign-in, embedded dashboards and scheduled email delivery depend on settings that an upgrade can affect. SSO through JWT, OIDC or SAML needs a Pro or Enterprise plan, and all SSO-based embedding does too. Check each path with a test user, a test embed and a scheduled send to a test address after every upgrade.
Custom SQL and API scripts fail
Native SQL questions, API scripts and serialization files written against one release can return different results or fail on a later one. Keep an inventory of custom questions, models and API calls with their expected outputs. Check them against a restored copy of the application database and a test data source before the upgrade reaches users.
Recurring costs after go-live
This table lists the recurring cost lines of a self-hosted Metabase instance, who is paid for each, and what drives it up or down.
| Cost line | Who is paid or what it covers | Recurring or one-time, and what drives it |
|---|---|---|
| Hosting for the application and application database | Your cloud account or data center. Confirm current instance and storage rates with your provider. | Recurring. Driven by instance count, database size, high availability and region. |
| Backup storage and retention | Your storage provider. Covers application database backups taken before each upgrade and on a regular schedule. | Recurring. Grows with retention period, backup frequency and database size. |
| Staging environment kept in step with production | Infrastructure you pay for, plus staff time to keep versions and configuration matched to production. | Recurring. Adds a second hosting footprint and a refresh after each upgrade. |
| Metabase plan | Open Source is free. Starter $100 per month, Pro $575 per month, Enterprise from $20,000 per year. Source: Metabase pricing page. | Recurring for paid plans. Driven by edition needed for SSO, row-level permissions and auditing. |
| Annual billing option | Starter $90 and Pro $517.50 per month when billed yearly. Source: Metabase pricing page. | Recurring. Lower monthly rate in exchange for a yearly commitment. Confirm terms with Metabase. |
| Additional users on paid plans | $6 per month each on Starter and $12 per month each on Pro, after included users. Source: Metabase pricing page. | Recurring. Rises with each licensed user, so count users who need a login before choosing a plan. |
| Upgrade effort per release | Labor for each release: backup, upgrade, testing and rollback plan. LTS support lasts 14 months. Source: Metabase version support page. | Recurring. Non-LTS releases usually reach end of life after 2 months, so they arrive more often. |
| Support retainer | Optional ongoing fee to a partner for monitoring, upgrades and fixes. Priced from the written scope. | Recurring. Set by the agreed response scope, upgrade cadence and testing frequency. |
| Internal skills to run the instance | Staff time for patching, monitoring, access reviews and user requests. | Recurring. Depends on user count, number of data sources and how often releases ship. |
How the work changes by starting point
A single node on a virtual machine is the simplest starting point. The JAR runs under a service manager on one host, so the plan centers on one backup, one maintenance window and one rollback path.
- Application database: confirm whether it already runs on PostgreSQL or MySQL, or still uses the embedded H2 database (covered in its own tab).
- Backups: confirm where the application database backup is stored, who can restore it and how long a restore takes in your environment.
- Maintenance window: confirm who approves downtime and how users and content owners are told.
- Runtime: confirm the Java runtime version required by the target release, using the upgrade notes for that release.
- Rollback: keep the previous JAR on the host and confirm the pre-upgrade backup restores cleanly before the upgrade starts.
Several instances behind a load balancer share one application database. The upgrade procedure changes because the migration lock requires reducing the cluster to a single node for a major upgrade.
- Cluster size: confirm how many nodes run today and how you will reduce to one node and then bring the others back.
- Load balancer: confirm the health check path and how traffic is drained from nodes during each step.
- Migration lock: plan the single-node window before any change to the shared database.
- Database access: confirm the application database role, and that backups cover the shared database as a whole.
- Configuration parity: confirm every node runs the same version and the same environment settings, including the encryption key, before the cluster is restored to full size.
An install still on the embedded H2 database needs a database move before a standard upgrade plan applies. The load-from-h2 command must run with the same Metabase version that last updated the H2 file, so the first step is identifying that version.
- Version match: confirm the version that last wrote the H2 file from server logs, deployment records or the team's change history.
- Target database: confirm whether PostgreSQL, or MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4, is the destination.
- Backup: copy the H2 file to a safe location before any step runs.
- Window: confirm the outage window with business owners and freeze changes to dashboards and users while the move runs.
- Checks: confirm users, saved questions, dashboards and scheduled jobs after the switch, against a list agreed before the move.
An instance several releases behind needs stepped upgrades. The documentation recommends upgrading release by release from versions older than 40, so the plan is a sequence of checkpoints, each with its own backup and test.
- Current version: confirm the exact version in use, and whether the instance runs a custom build.
- Upgrade path: confirm the intermediate releases and the target. Metabase 64 is an LTS release with end of life on 1 December 2027, and Metabase 65 was released on 12 October 2026, according to the version support page.
- Support status: confirm which releases on the path still receive security fixes on the dates you plan to run each step.
- Testing: confirm a staging copy of the application database and a sample of questions and dashboards for each step.
- Quote basis: ask the partner to list each step, its backup, its test and its rollback point, since the number of steps follows from the starting version.
Packaging changes where artifacts come from and how they are replaced. In containers or Kubernetes, image tags and rollouts drive the upgrade. In an air-gapped or restricted network, the JAR and images must be delivered internally before any step can run.
- Image source: confirm whether official images are mirrored to an internal registry and who approves each image before it is used.
- Rollout: confirm the deployment strategy and how the upgrade migration runs once, so that only one instance performs it.
- Delivery: confirm the transfer process for the JAR, images and any plugins, including checksum verification on the internal side.
- Network: confirm which outbound connections the instance needs and which are blocked, since blocked connections change the test plan.
- Rollback: keep the previous image or JAR available inside the network and confirm the application database restore is tested.
What the client needs to provide
Before DeployOpen touches a Metabase upgrade, the client supplies a named technical owner who makes configuration and rollback decisions, and a business owner who signs off that the upgraded instance is fit for use. Without both names in writing, the upgrade stalls at the first question about a changed dashboard or a failed scheduled delivery, because nobody has the authority to accept the result. Access is the next dependency. The team needs access to the host or cluster running the Metabase JAR or container, and admin rights on the application database (PostgreSQL or MySQL in most production installs). Upgrades run application database migrations automatically, so the database account must be able to alter schema. Confirm whether the database is H2, which is the default for demos and needs a separate migration path before any upgrade planning.
Backup storage is the safety net for rollback. Metabase's upgrade guidance recommends backing up the application database before upgrading, and rollback is most reliably done by restoring that backup. The client should name where backups land, who can read them, and how long they are kept. A staging environment, or permission to create one, matters because a copy of the production application database lets the team rehearse the migration and test queries, embeds and SSO logins before users see the change. The client also provides a maintenance window the business accepts. For a major upgrade on a clustered deployment, the cluster must be reduced to a single node because of a migration lock, so users lose redundancy and may lose access for a period. Supply an inventory of data sources, custom content (models, metrics, native questions), scheduled deliveries, embedded applications and SSO configuration records, plus the change approval process. These records show what must be retested after the upgrade.
Frequently asked questions
What drives the cost of a Metabase upgrade and how is a quote built?
The cost comes from the scope written before work starts, not from a list price. DeployOpen does not publish prices, and a quote follows from the agreed scope. The main components are the number of instances and whether you run a cluster, the state of the application database, how many release steps lie between your current version and the target, the size of your custom content such as models, custom SQL and embedded dashboards, and the testing you require before cutover. Ask for a quote that lists each component, what is one-time and what recurs, and which items are your responsibility, such as change windows and access to your infrastructure.
How long does a Metabase upgrade take and what sets the timeline?
No duration is fixed here, so confirm the timeline against your own environment and the written scope. The main variables are the number of release steps, because Metabase recommends upgrading release by release from versions older than 40, the size of the application database and how long its backup and restore take, whether you must reduce a cluster to a single node for a major upgrade, and how much regression testing your dashboards, permissions and embeds need. Approval windows and the availability of your staff for sign-off also set the calendar.
Can our own team run a Metabase upgrade without a partner?
Yes, many teams do, provided they have a Linux operator who can manage the JAR or container, database administration skills for a PostgreSQL or MySQL application database, and someone who can validate reports, permissions and SSO after the change. The upgrade itself runs database migrations automatically, so the risky steps are the backup, the cluster reduction for major upgrades and the rollback plan. Check your team's capacity against your release calendar, and confirm the exact procedure against the current upgrade documentation for the target version.
How often must a Metabase instance be upgraded given LTS and non-LTS releases?
Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after about 2 months. Any release that is past its end-of-life date stops receiving bug fixes and security updates, so an instance on a non-LTS line needs to move quickly, while an LTS line gives you a longer window. Choose a target LTS release and plan a path to it, and check the version support page for the end-of-life date of your current version. Metabase 64 is an LTS release with an end-of-life date of 1 December 2027.
What happens if a Metabase upgrade fails and when should we roll back?
Roll back when the new version fails to start, migrations stop partway, or critical content is wrong and cannot be fixed quickly. The recommended rollback is restoring the application database backup taken before the upgrade, then starting the previous JAR. Metabase also documents running the migrate down command with the newer JAR, but restoring the backup is the safer route. Confirm before the change window who makes the rollback decision, how long a restore takes in your environment, and whether any data entered during the failed window must be preserved.
Does upgrading Metabase change the edition or plan we need?
An upgrade does not change your plan by itself. Your edition is determined by the software and license you run, and features such as SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in the Pro and Enterprise plans. Before upgrading, confirm which features you rely on and check the pricing page and license terms for the target version, since the list of what each plan includes is set by Metabase and may change.
What does DeployOpen support cover after go-live?
Post go-live support is defined in the written scope. Typical items include help with incidents, monitoring checks, backup verification, patch and version planning, and assistance with the next upgrade. Ongoing support, upgrades and continuous testing are available as retainers. Ask for a written description of response expectations, the systems covered, and what is excluded, and confirm how DeployOpen access to your infrastructure is granted and reviewed in your environment.
How DeployOpen delivers upgrades and support
DeployOpen plans, runs and documents Metabase upgrades inside your own infrastructure, from a written scope through to post-go-live support. Engagements are fixed-scope, and ongoing support can be added as a retainer.
How we scope
- Inventory your Metabase version, install type, application database and the data sources connected to it.
- Confirm which target release fits your support window, using Metabase's LTS and non-LTS end-of-life dates.
- Agree in writing what is covered: upgrade steps, backup and rollback procedure, testing and post-upgrade checks.
How we build
- Take and verify a backup of the application database before any change, and confirm it can be restored.
- Rehearse the major upgrade in a non-production copy, release by release where the installed version is older than 40.
- Reduce a clustered deployment to a single node for the major upgrade, because of the migration lock, then restore capacity.
How we hand over
- Document the target version, the upgrade run book, the rollback steps and the tested restore procedure for your team.
- Walk your administrators through the post-upgrade checks on login, permissions, collections, sources and scheduled jobs.
- Record the open items and the next Metabase end-of-life date so your team can plan the following upgrade.
How we support
- Offer ongoing support, upgrades and testing as a retainer once the initial upgrade is complete.
- Review new Metabase releases against your environment and propose upgrades within your support window.
- Confirm the support hours, response expectations and escalation path in the written agreement before work starts.
