Metabase 64 LTS upgrade

Staying on an LTS line is mainly a decision about how long security fixes keep arriving. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after about 2 months. Every release receives bug fixes and security updates until its own end-of-life date, so a non-LTS version is still patched while it is current. The difference is the window. A non-LTS release gives your team a short time to test and move before patches stop, which is why teams that must keep a stable platform usually plan around the LTS line. Check the Metabase version support page before you start, because the dates that govern your plan are the ones published for the exact version you will run.

For this upgrade, the planning consequence starts with the date. Metabase 64 is an LTS release published on 16 September 2026, and it is supported until 1 December 2027. That gives your team a fixed horizon by which it must either run a supported release or have moved on to another one. Work backward from that date against your change calendar. Count the change windows you have before it, and confirm whether a single window can cover the application database backup, the JAR or container swap, the single-node step required for a major upgrade, and post-upgrade verification. Do not treat the end-of-life date as the deadline for the move. Treat it as the outer limit, and schedule the work well inside it.

The choice between 64 and 65 depends on two inputs: your change window and the controls you must evidence. If your change calendar allows one planned window with limited room for rework, a long patch horizon on the LTS line reduces the number of times you must repeat this exercise. If your assessors require a version under vendor patching for a defined period, document the 64 end-of-life date in your control narrative. Metabase 65 was released on 12 October 2026, so confirm its support window on the version support page before you compare it with 64. Then ask whether any behavior your controls depend on, such as SSO, permissions or audit logging, changes between the two releases, and whether your team can test that before production.

Write the decision down before the change window is booked. Record the target version, its end-of-life date, the window and the rollback path. The rollback path is restoring the pre-upgrade application database backup, which is the recommended method, or running the migrate down command with the newer JAR. Also record the controls each target version must support. Some of them depend on your plan. SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in the Pro and Enterprise plans. If your current plan does not include a control your evidence requires, that gap is a licensing question to resolve before you pick the target, not during the upgrade.

If your Metabase instance runs a version older than 40, the upgrade documentation recommends moving to 64 one release at a time, not in a single jump. Treat the intermediate stops as part of the project plan from the start, because they determine how many upgrade cycles you run, how many backups you take, and how many test rounds your team needs. A direct swap of the JAR or container image from a very old version to 64 is outside the documented path, so it should not be the plan for any environment, including a test instance that will later be promoted. Start by confirming the exact running version. Check the version shown in the Metabase admin area, the image tag or the JAR filename, and record it with the application database type. Then use the upgrade documentation for that starting version to list the intermediate releases to stop at, in order. Do not assume a list from memory or from another customer's upgrade. Ask the partner or your own team to write the sequence into the change plan with a target release for each step, and confirm that the sequence ends at 64 and not at a release that will reach end of life sooner.

Each intermediate stop is a full upgrade. When Metabase starts on a new JAR or container image, it runs its application database migrations automatically. Those migrations change the schema and stored data that Metabase uses for questions, dashboards, permissions, users and settings, and older versions often carry migrations that were written for a different database layout. Because each step applies its own set, the application database changes once per stop. Plan for the startup time and the migration output at every step, and review the logs for errors before you move to the next release. The single-node rule for major upgrades still applies. The documentation asks you to reduce a cluster to one node while migrations run because of a migration lock. Schedule the node reduction, the upgrade and the return to a cluster separately for each stop that crosses a major version boundary, and confirm with the upgrade documentation which stops count as major for your path.

Each step needs its own application database backup and its own smoke test. The reason is rollback. Metabase can be rolled back either by restoring the pre-upgrade application database backup, which the documentation recommends, or by running the migrate down command with the newer JAR. Restoring a backup taken before step three returns the instance to the state after step two, and a single backup taken before step one would force you to return to the starting version and repeat the whole path. Name each backup with the source and target versions, store it outside the instance, and confirm that a restore works on a test host before you rely on it. A smoke test after each stop should be short and repeatable. Sign in with a standard user and an administrator account, open a sample of saved questions and dashboards, run a query against each connected data source, check that scheduled subscriptions and alerts still send, and confirm that any single sign-on or LDAP login still works. Record the results so that a failure can be tied to a specific release.

Ask for a written plan before work starts. The plan should list the starting version and the confirmed stops from the documentation, the backup and restore method for each stop, the test cases in the smoke test, the maintenance window needed for each stop, and the point at which the team will decide to roll back. Ask who will perform each restore and how long a rollback is expected to take in your environment, since those depend on your database size and infrastructure. Finally, confirm the lifecycle of the target. The Metabase version support page lists Metabase 64 as an LTS release published on 16 September 2026, with end of life on 1 December 2027, so confirm that date on the page before you set the support calendar.

For a major Metabase upgrade, the docs recommend reducing a cluster to a single node before you swap the JAR or container. The reason is the migration lock on the application database. Metabase runs its application database migrations automatically on startup, and those migrations need exclusive control of the schema while they run. If older nodes keep serving traffic and writing to the same database during that step, the upgrade can stall or leave the instance in a state that is hard to recover. Before you schedule the window, read the upgrade documentation for your topology and confirm the exact sequence for your setup, whether that is a VM group, containers behind a load balancer, or an orchestrated deployment.

The reduced capacity window is the first thing to plan around. With one node serving, every dashboard load, ad hoc query, scheduled subscription and alert depends on that single instance. Pull current concurrency and peak usage from your own monitoring, not from estimates, and pick a window outside your heaviest reporting periods. Tell analytics users, data owners and anyone who depends on scheduled delivery when the window starts and when they should expect normal service. Decide in advance whether scheduled jobs will be paused, moved or allowed to queue, because a job that fires during the migration can add load or fail in ways that are hard to read later.

Removing and re-adding nodes needs a written order of operations. Drain the nodes you are removing from the load balancer, stop them, and keep their software at the old version until the upgraded node is healthy. Confirm that the application database is the same one all nodes point to, and that every node uses the same encryption key and configuration values before you start the next node. Add the remaining nodes back one at a time on the new version, checking health after each one. Ask the team that owns the cluster to record which node was upgraded first, which version each node runs and when each was re-added, so that a later problem can be traced to a specific step.

The load balancer and session behavior change during the window. With one node, the balancer should send all requests to that node and stop routing to nodes that are down or still on the old version. Health checks need to reflect the single-node state, or the balancer may mark the only healthy node as failed. Test whether user sessions survive the switch by logging in, upgrading, and confirming that an existing session still works or that users are prompted to sign in again. If your deployment depends on sticky sessions or node-local state, confirm how it behaves before the window. Include rollback in the plan: if the upgraded node fails, restore the pre-upgrade application database backup before you re-add any other node.

Decide your rollback route before the change window opens. Metabase's upgrade documentation describes two ways to undo an upgrade: restoring the application database backup taken before the change, which the docs recommend, or running the migrate down command with the newer JAR. The two behave differently, so the change plan should name the route you will use, the person who will execute it, and the conditions that trigger it. The restore route only works if the backup exists, is complete and has been checked. Confirm the backup method for your application database engine, whether PostgreSQL or MySQL, and store the backup where the rollback team can reach it during an outage.

A restore returns the application database to the state it had when the backup was taken. Anything written after that point is lost, including saved questions, dashboards, collections, user accounts, permission changes, database connection settings and alert or subscription configurations. If business users worked in the upgraded instance for hours, that work disappears unless you reconcile it. Decide in advance how to handle the window. You can accept the loss and tell users which content to recreate, or you can export content created during the window, such as dashboards and questions, and rebuild it after the restore. Record that decision with the business owners before the upgrade starts, not during the rollback.

Running migrate down with the newer JAR reverses schema migrations in place instead of replacing the database, which can keep changes made after the upgrade. That benefit depends on the reverse migrations completing cleanly, and the newer JAR must still start far enough to run them. A failed migration can leave the database in a state that neither route handles well. Confirm with the upgrading documentation which versions support this path and what state the database must be in. Treat migrate down as the secondary option, and keep the verified backup in place whichever route you choose so you always have a known-good copy to restore from.

Rehearse the restore on staging before the change window. Restore the pre-upgrade backup into a staging environment that matches production's database engine and version, start the older JAR against it, and check sign-in, data source connections, a sample of saved questions and dashboards, and scheduled jobs. Time each step, record every manual reconciliation action and note which users or teams need notice. The rehearsal should also confirm that the single-node reduction required for major upgrades can be reversed in your environment. Use the results to set go or no-go criteria and to define how long the team will wait before starting the rollback.