Metabase high availability: when one node is no longer enough
High availability for Metabase means running several instances behind a load balancer, all pointing at one shared application database. The hard parts are that shared database, how user sessions are handled across nodes, how many nodes each environment needs and how much CPU and memory each one gets, and how the upgrade procedure changes once more than one node is running. Analytics users feel an outage quickly. Dashboards stop loading, scheduled questions may fail to run, and a single Metabase JAR on one host is a single point of failure for everyone who depends on it. Adding nodes helps only when each one runs the same version and configuration.
The shared dependency is the application database, which stores Metabase's own configuration, users, saved questions, dashboards and permissions. The databases Metabase queries for analysis are separate and sit outside this design. Metabase recommends PostgreSQL for production. The embedded H2 database that ships for demos cannot be shared between instances, so a cluster cannot run on it. MySQL and MariaDB are also supported, with version minimums and a utf8mb4 character set requirement that you should confirm in the application database documentation for your release before you choose. If you are moving an existing install off H2, the load-from-h2 procedure has its own rule that the Metabase version must match the one that last wrote the H2 file.
Upgrades are where a cluster differs most from an ordinary stateless web application. Metabase runs application database migrations automatically when a newer JAR starts, so the nodes cannot simply be replaced one at a time. Metabase's upgrade documentation recommends backing up the application database first and reducing the cluster to a single node for major upgrades because of a migration lock. Plan a maintenance window for that step, and confirm in the upgrade guide for your source and target versions whether minor upgrades follow the same rule. Also confirm the rollback path. Restoring the pre-upgrade backup is the documented recommendation, and running the migrate down command with the newer JAR is the alternative.
Before you build, make several decisions and confirm the rest in writing. Decide where TLS terminates and which path the load balancer uses for health checks, then confirm the health endpoint and its expected response for your version. Decide how many nodes you need for your failure tolerance and peak query load, and validate that number with a load test on your own data. Confirm session behavior in the documentation for your release, including how a user's login survives a node failure and whether the load balancer must keep each user on one node. Finally, confirm which Metabase line is current LTS and how long it is supported, because the cluster should stay on a supported version.
Components in a Metabase cluster
A Metabase cluster has six parts that must be designed together: the application nodes, the load balancer, the shared application database, the data source connections, the shared settings, and the TLS termination point. Each has a different owner, and a fault in any one of them can stop every user, even when the other parts are healthy.
Metabase JAR nodes
Each node is a running Metabase JAR that serves the web application, the API and query processing. Nodes keep user data in the application database rather than locally, so a failed node can be replaced without losing content. Every node must run the same Metabase version, and a restarted node should rejoin without manual steps. When one node stops, remaining nodes absorb its traffic, but users see slower responses if capacity is no longer sufficient. Owner: platform engineering.
Load balancer in front of nodes
The load balancer distributes user requests across nodes and removes unhealthy nodes from rotation. Its health checks should target the health endpoint documented for your Metabase version, so confirm the path before go-live. If the load balancer fails or is misconfigured, users lose access even though every node is running, which makes it a common single point of failure. Confirm session handling, such as whether sticky sessions are needed, with the vendor documentation for your setup. Owner: network or platform team.
Shared PostgreSQL application database
The application database stores users, permissions, saved questions, dashboards and system settings for all nodes. It is the one component every node writes to, so its availability and backup schedule determine the cluster's recovery point. Metabase recommends PostgreSQL for production. During major upgrades, the migration lock means the cluster must be reduced to a single node, so plan that window with the database team. Owner: database administration, with the platform team consulted on connection limits.
Customer data source connections
Connections to warehouses and operational databases sit outside the cluster, and each node opens its own connections to them. Data owners control those sources, and their availability only affects questions that query them. Network rules must allow traffic from every node's address, and a new node that cannot reach a source will show query errors only for that source. Credentials for these connections are stored in the application database, so their handling belongs in the security review. Owner: data owners, with the platform team managing network access.
Shared encryption and configuration
Every node must share the same encryption key, site address and configuration values, including settings for authentication. The encryption key protects sensitive values stored in the application database, so a node with a different key cannot read them correctly. Mismatched settings typically cause inconsistent behavior that is hard to diagnose from user reports. Store these values in a managed secrets process and confirm the full list of values that must match in the Metabase configuration documentation. Owner: platform team with security approval.
TLS termination point
The TLS termination point is where encrypted client connections are decrypted, either at the load balancer or at each node. It holds the server certificates, the protocol and cipher policy, and the renewal process. An expired or misconfigured certificate blocks every user at once, so renewal alerts should reach the team that owns the certificate. Decide whether traffic between the load balancer and nodes is encrypted, and confirm that the configured site address matches the external URL users see. Owner: security and network teams.
Which HA design fits your Metabase environment
This table compares three ways to run Metabase, from a single node with fast restore to clustered nodes on managed or self-managed PostgreSQL. Read each row for the fit, the recurring operational work, and the session and placement questions to confirm before you choose. The main takeaway is that every clustered design adds database and upgrade work that a single node avoids, so settle who operates the database first.
| Design | When it fits | Operational cost | Session and placement to confirm |
|---|---|---|---|
| Single node with backups and fast restore | Internal analytics where a short outage during a restore is acceptable and the team can rebuild quickly | Backup verification, restore drills, and a tested rebuild path for the host and application database | No load balancer session question. Confirm the restore time your business owners will accept. |
| Two or more nodes behind a load balancer on managed PostgreSQL | Teams that need node-level failover but want the cloud provider to run database backups and host maintenance | Health check tuning, managed patch windows, failover tests, and a rehearsed upgrade runbook | Confirm in the Metabase docs for your version whether sticky sessions are required. Spread nodes across zones where the platform allows. |
| Two or more nodes behind a load balancer on self-managed PostgreSQL | Organizations with a standing database team, strict data residency rules, or existing PostgreSQL replication standards | Your team patches the database, runs replication and failover, tests promotion, and owns backups | The same session questions apply. Keep database replicas and Metabase nodes on separate hosts or zones. |
| Clustered upgrades on any design | Teams that run clusters and need predictable change windows | The migration lock means a major upgrade runs on one node, so plan a maintenance window | Confirm the upgrade steps for your version in the upgrade docs before scheduling. |
| Health checks and node removal | Clusters that need unhealthy nodes removed from rotation automatically | Alerts on node errors and database connection failures, plus periodic review of thresholds | Confirm the health check path and expected response in the Metabase docs for your version. |
How to build a Metabase cluster on a shared PostgreSQL database
This sequence builds a Metabase cluster in which several identical nodes share one PostgreSQL application database and sit behind a load balancer. Each step closes with a check, so you know the database, nodes, balancer and scheduled delivery work before users depend on them. The result is a cluster you can restart one node at a time, with upgrade steps covered separately.
Provision PostgreSQL for the application database
The database administrator creates an empty PostgreSQL database and a dedicated role for Metabase, limiting that role's privileges to this database. Choose a PostgreSQL version listed as supported in the Metabase application database documentation for the Metabase release you plan to run. Confirm the database encoding is UTF-8 so character handling matches what Metabase expects for multilingual names and comments. Done when you can connect with the new role from a host on the Metabase subnet and the server reports the expected version and encoding.
Complete the one-time H2 load if applicable
Skip this step on a new install. If an existing Metabase runs on the embedded H2 database, complete the one-time load-from-h2 procedure described in the H2 to PostgreSQL migration topic before adding any node. Run the load with the same Metabase version that last wrote the H2 file, because a different version can fail or change the schema. Done when the load finishes, one node starts against PostgreSQL, and users, questions and collections match the H2 source.
Start the first node against PostgreSQL
Set the connection settings so the first node points at the PostgreSQL application database, including database type, host, port, name, user and password. Set the encryption secret key once and store it in your secrets manager, because every node must reuse it. Start the JAR and let it finish its migrations before you start anything else. Done when the log shows migrations completed without errors and the login page loads in a browser.
Configure additional nodes with identical settings
Give each additional node the same application database settings, the same encryption secret key and the same Metabase version as the first node. Mismatched keys or database targets tend to cause login, session or stored credential failures that are hard to trace. Start the nodes one at a time and watch each log for a clean startup with no migration activity. Done when every node reports the same version and reads the same application database.
Place the load balancer in front of nodes
Create a balancer pool with every node as a target and a health check against the health endpoint documented for your Metabase version. Confirm the exact path and expected response for that version before relying on it. Test each node address directly as well as through the balancer to confirm the health check reaches every node. Set the site URL to the balancer address if your deployment requires it. Done when every node shows healthy in the pool.
Test login, saved questions and scheduled delivery
Run three checks through the balancer address: sign in as a standard user, open a saved question that queries a connected data source, and trigger a scheduled delivery to a test recipient. Repeat the sign-in several times so requests land on different nodes. Scheduled delivery depends on email or chat delivery settings, so confirm those are configured and tested before go-live. Done when each check passes and the same results appear regardless of which node served the request.
Test a node restart and continued service
Stop one node while a test user stays signed in, then run a query through the balancer. Confirm the balancer removes the stopped node from rotation and the remaining nodes keep serving pages and queries. Restart the node and confirm it rejoins the pool once its health check passes, with a normal startup and no migration run in its log. This test does not cover upgrades, because migration locks change that procedure, so review the Metabase upgrades and support topic before any version change. Done when the test is documented so it can be repeated.
How the migration lock changes the upgrade procedure in a cluster
In a Metabase cluster, a version upgrade is not a rolling change. Metabase runs its application database migrations automatically when a node starts on a newer version, and the upgrading documentation recommends reducing the cluster to a single node for major upgrades because of a migration lock. The load balancer, health checks and node count therefore have to be part of the change plan, not an afterthought. Before scheduling the work, confirm with the upgrading documentation whether your target version is a major upgrade and which node-reduction steps it requires, since those steps are version specific.
The sequence starts with a fresh backup of the application database, which is the PostgreSQL database holding Metabase's own configuration, users and saved content. Next, stop every node except one and remove the stopped nodes from the load balancer pool so that no traffic reaches them. Upgrade the remaining node, then confirm it is healthy: the application should start cleanly, the logs should show the migrations completing without errors, users should be able to sign in, and a saved question should run against a connected data source. Only after that check should the other nodes be brought up, and they must run the same version as the upgraded node. Mixed versions in one cluster are the outcome to avoid.
If your installation is older than version 40, the documentation calls for upgrading release by release rather than jumping straight to the target. Each step in that path runs its own migrations, so each one needs its own application database backup and its own health check before the next step begins. Build the path in the plan before the maintenance window, list every intermediate version, and ask the team that owns the upgrade to confirm the node-reduction steps for each one. A plan that assumes a single jump will understate both the number of windows and the time needed for testing between them.
Rollback has two documented options. The recommended option is to restore the pre-upgrade application database backup, which returns the database to the state it was in before the migrations ran. The other option is to run the migrate down command with the newer JAR, which reverses migrations using the newer code. Decide which option you will use before the upgrade starts, rehearse it in a non-production environment, and record the exact commands and backup location in the runbook. Restoring a backup also means that any configuration or content changes made after the backup will be lost, so agree on a freeze period for changes during the window.
Version support sets how often this procedure has to run. Metabase LTS releases are supported for 14 months, while non-LTS releases usually reach end of life after about 2 months, so a cluster on a non-LTS release needs an upgrade cadence that is much faster. Metabase 64 is an LTS release with end of life on 1 December 2027, which gives teams a fixed date to plan around. Check the version support page for the current end-of-life dates for any release you run, and schedule the next upgrade window before the current version reaches that date.
What drives the effort of a Metabase HA rollout
This table lists the factors that raise or lower the effort of a clustered Metabase rollout, with how each one changes the work and how to keep it manageable. Read it before asking for a quote, since the drivers that matter most are the ones your own environment already exposes. The main takeaway is that the application database, the number of environments, and the upgrade path usually shape effort more than raw user counts.
| Driver | Effect on effort | How to keep it down |
|---|---|---|
| Users and concurrent dashboard use | Higher concurrency means more instances, more load balancer tuning, and more load testing before go-live. Peak times with many simultaneous dashboard refreshes matter more than total headcount. | Confirm expected peak concurrency with the business owner, limit auto-refreshing dashboards, and schedule heavy extracts off-peak. |
| Data source connections | Each connected database adds connection pool sizing, network paths, credentials, and query tuning across nodes. Many large or slow sources increase testing and troubleshooting. | Inventory sources first, retire unused connections, and use read replicas or a reporting database for heavy analytical workloads. |
| Managed application database already in place | An existing managed PostgreSQL service with backups, failover, and monitoring removes a large build task. Without one, the team must provision, secure, back up, and monitor the database as part of the cluster. | Confirm whether your platform team already runs managed PostgreSQL with point-in-time recovery, and reuse it if the sizing and access model fit. |
| Number of environments (dev, staging, production) | Each environment needs its own cluster, load balancer, database, and configuration. Keeping them consistent is ongoing work, and a staging cluster that does not mirror production weakens upgrade testing. | Use infrastructure as code with one shared template, keep staging close to production in topology, and limit extra environments to what testing needs. |
| Current version and distance from the latest release | Being several releases behind means more migrations to run in order. Metabase recommends upgrading release by release from versions older than 40, and each step in a cluster needs planning around the migration lock. | Stay within the supported window for your LTS or non-LTS line, and schedule upgrades regularly so the gap does not grow. Ask the vendor or partner to confirm the upgrade path before estimating. |
| Customization and embedding | Custom models, metrics, native SQL, branding, and embedded dashboards add configuration and regression tests for every upgrade. Embedding also brings its own authentication choices and plan requirements. | Keep customizations documented and version-controlled, limit embedded content to what is needed, and confirm which embedding methods your plan supports. |
| Identity integration | SSO through SAML, OIDC, JWT, or SCIM requires identity provider configuration, group mapping, and testing in each environment. On the free edition, Google sign-in or LDAP are the available options, which changes the design work. | Decide the identity model before building the cluster, map groups to permissions in a written matrix, and confirm which features your plan includes. |
| Compliance evidence requirements | Assessors often ask for backup records, access reviews, change logs, and proof of upgrade testing. Collecting this evidence across several nodes and environments adds documentation and monitoring work. | Agree the evidence list with your auditor early, centralize logs, automate backup verification, and keep upgrade test records for each release. |
Securing the shared application database and cluster nodes
Every Metabase node in a cluster reads and writes the same application database, so a weak control there affects the whole deployment. The cards below cover the controls that matter most when several instances share one database, from database isolation and credentials to encryption keys, endpoint access and backups. Permissions and sharing settings are covered in the security hardening topic and are not repeated here.
Dedicated database for Metabase only
Give the cluster its own PostgreSQL application database that no other application uses. Metabase stores users, groups, saved questions, dashboards and permission settings there, so sharing a database with unrelated workloads widens who can read or alter that data. Confirm that the database instance, schema and backups are scoped to this one deployment, and record which team owns each of them.
Least-privilege database credentials
Create a database role used only by Metabase, with rights limited to its own application database and no superuser or cross-database privileges. Schema changes run during upgrades, so confirm with your DBA how migration rights are granted and when they are revoked afterwards. Store the credentials in a secrets manager and rotate them through a documented procedure that restarts all nodes in turn.
Database kept off public networks
Place the application database on a private subnet reachable only from the Metabase nodes and approved administration hosts. Remove any public IP address and restrict inbound rules to the node security group or equivalent. Check the rules from outside your network as well as inside, because a database exposed by a single misconfigured rule is a common failure in self-hosted clusters.
TLS on every connection path
Encrypt traffic between users and the load balancer, between the load balancer and each node, and between the nodes and the application database. Require TLS on the database side, not only on the client, and confirm that certificate validation is enforced rather than skipped. Plan certificate renewal for every hop, since an expired certificate on one node can take that node out of rotation without an obvious error to users.
Matching encryption key and secrets on all nodes
Metabase uses an encryption key to protect stored credentials for connected data sources. Every node must use the same key and the same configuration secrets, or nodes will fail to read data that another node wrote. Keep one source of truth for these values, deliver them identically at deploy time, and record who can read them. Losing the key without a backup can make stored connection credentials unrecoverable.
Restricted admin console and health endpoints
Load balancers need the health endpoint, but it should not be reachable from the internet or from user networks that have no need for it. Limit access to the admin console to named administrator networks, and confirm which paths the load balancer forwards publicly. Review these rules after each change to the load balancer, because a permissive path rule can expose administrative pages without any application change.
Application database backups as sensitive data
Backups of the application database contain user accounts, group membership and permission structures, so they need the same protection as the live database. Encrypt them, limit restore access to a named group, and keep them out of shared storage buckets. Test restores into an isolated environment, and confirm retention periods with your compliance team before the first upgrade, since upgrade rollback depends on the same backups.
How to test that the cluster survives a node failure
A node failure test shows whether a Metabase cluster is available when one instance stops, but the result depends on three parts working together: the load balancer's health checks, the shared PostgreSQL application database, and the Metabase JAR running on each node. Write the test cases as pass or fail statements before anyone stops a server. Each case should name the component it exercises, the expected result, and the evidence you will keep, such as load balancer logs, Metabase logs and the database state before and after.
Start by proving that each node answers on its own. Send health check requests directly to every node, bypassing the load balancer, and confirm that each one reports healthy and can load the sign-in page. Confirm the health check path and its expected response in the Metabase documentation for your version, since the path is not something to assume. Then remove one node from the load balancer pool and confirm that new traffic moves to the remaining nodes without visible errors. Record how long the balancer takes to mark a node unhealthy, because that interval decides how many users see failures during a real outage.
Next, stop one node while a light, scripted load runs. Use a set of signed-in test accounts that open saved questions and dashboards, and include one scheduled subscription or alert. Sessions on the surviving nodes should continue without interruption. Users whose sessions were on the stopped node should see an error or sign-in prompt on their next request, and should land on a working node after signing in again. Confirm in the vendor documentation how sessions are stored and whether they survive a node restart. For scheduled work, check which node runs each job and confirm that the job runs once, neither skipped nor duplicated, in line with the behavior the documentation describes for your version.
Then test the database and data consistency. Restart the PostgreSQL service and confirm that every node reconnects without a manual restart. Make a change on one node, such as a new user, a collection move or a permission group update, and confirm that every other node shows the same users, collections and permissions after the change. The safe failure case is a database outage: requests should return errors, not cached pages, stale permissions or another user's results. If you use row-level or column-level permissions, add test accounts that check those rules during the outage and after recovery, and confirm with the documentation which plan includes them.
Finish with an upgrade rehearsal on a copy of the application database, restored into a staging cluster built to match production. Run the single-node step that the upgrade documentation requires for major upgrades, confirm that the migration lock behaves as described, and then practice restoring the pre-upgrade backup. Time each step with your own measurements and use those figures for planning, not any published estimate. Confirm the required version path with the upgrade documentation for your starting version. The step-by-step upgrade procedure belongs to the upgrades and support section, so this rehearsal should focus on whether your team can complete the sequence and recover from it.
What to monitor, back up and document after go-live
This table lists the operational duties that keep a clustered Metabase running after go-live, with what each duty covers and what to confirm in your environment. Read each row as a standing task with an owner, not a one-time setup step. The main takeaway is that the upgrade calendar and the pre-upgrade backup are tied together, so they should be owned by the same person.
| Area | What to watch or do | Evidence to keep |
|---|---|---|
| Node health | Poll each node's health endpoint through the load balancer and directly, and alert on repeated failures or slow responses | Alert rules, probe history and the node each alert named |
| Application logs | Collect logs from every node and watch for startup errors, migration messages and repeated database connection failures | Log retention settings and a saved query for cluster-wide errors |
| Load balancer | Monitor backend health states, failover events and certificate expiry at the balancer in front of the nodes | Balancer health check configuration and change history |
| Application database | Track availability and connection counts on the shared PostgreSQL application database, and confirm failover behavior if it runs as a replicated service | Database uptime reports and the documented failover test result |
| Storage and backups | Confirm each scheduled application database backup completes, is stored off the database host and is recent enough for your recovery goal | Backup job logs, storage location and a dated record of each backup |
| Restore testing | Restore a recent application database backup into a separate environment on a schedule and confirm Metabase starts against it | Restore test report with the Metabase version and the date tested |
| Scheduled delivery failures | Watch for failed subscriptions and alerts, since they can fail silently on one node while others keep serving users | Failure notifications routed to a named owner and a record of resolutions |
| Upgrade calendar | Map each planned upgrade to the LTS or non-LTS end-of-life dates on the version support page and schedule before those dates | Upgrade calendar with target version, end-of-life date and approver |
| Pre-upgrade backup | Take an application database backup before every upgrade, and confirm it is restorable because rollback relies on it | Backup timestamp tied to the change ticket and the restore check |
| Runbook and node inventory | Maintain a runbook covering node addresses, startup order, the single-node reduction for major upgrades and rollback steps | Versioned runbook and an inventory listing each node, version and owner |
| Encryption key custody | Record where the application database encryption key is held, who can access it and how it is recovered | Key custody record with named custodians and access approvals |
Questions about Metabase high availability cost and effort
What drives the cost of a Metabase high availability rollout?
The cost depends on five components: infrastructure, the PostgreSQL service, labor for the build, testing and runbooks, and ongoing support. Infrastructure includes at least two application nodes, a load balancer, monitoring and a non-production copy where upgrades can be rehearsed. Database cost depends on whether you run an existing managed PostgreSQL service with failover or build one. Labor covers architecture, configuration, health checks, failover tests and runbooks. Support covers patching, upgrades and incident response after go-live. Infrastructure and database costs usually recur, while build and test labor is one-time. When you request a quote, ask for a written scope that separates one-time work from recurring items and lists every environment included.
Is a single Metabase node with good backups enough?
For some teams it is, if they accept that a failed host means downtime until a restore finishes. Backups protect your data, but they do not keep dashboards, scheduled subscriptions and embedded analytics available during an outage. A restore needs a replacement host, the Metabase JAR, configuration and a restored application database, and each step takes time that your business must accept. Backups also do not remove the upgrade window. Metabase documents a migration lock, and it recommends reducing a cluster to a single node for major upgrades, so a cluster still needs a planned maintenance step. Back up the application database before every upgrade, test restores on a schedule, and decide how much downtime users can tolerate before you choose between a single node and a cluster.
Can our own team set up Metabase high availability without a partner?
Yes, if your team already has the skills the work needs and can rehearse before production. You need PostgreSQL administration skills for the shared application database, load balancer configuration and health check design, and enough Linux and deployment experience to keep several identical application nodes in step. Metabase recommends PostgreSQL for production, so an embedded H2 database must be moved first using the documented load-from-h2 process, which requires the same Metabase version that last updated the H2 file. Your team should also rehearse upgrades on a copy of production, including the single-node step for major releases and a tested rollback. If any of these skills are thin, a partner can cover the gaps while your staff learn the runbooks.
How long does a Metabase high availability project take?
The duration depends on the drivers in your environment, and no fixed timeline applies to every project. The main factors are whether a PostgreSQL service and load balancer already exist, how much identity and data source work is involved, how many environments need the same setup, and how many change windows your organization can offer for cutover and upgrade rehearsal. Each of these can move the schedule in either direction. DeployOpen works from fixed scope, and the scope, deliverables and timelines are agreed in writing before work starts. Ask for the timeline in that written scope, and ask which dependencies on your side could delay each milestone.
What does our team need to provide for a Metabase high availability engagement?
The work needs access, named owners and scheduled time from your side. Access includes hosts or cloud accounts, load balancer administration, DNS and TLS certificate management, and rights to create a PostgreSQL database and role for Metabase. People include a database owner who can approve schema and credential changes, a contact for your identity provider if SSO is in scope, and a contact for each data source Metabase will connect to, so connections and credentials can be tested. Time includes change windows for cutover, a window for rehearsing an upgrade and a named approver for production changes. Confirm these items in the written scope so that the engagement does not stall while access is requested.
Does Metabase high availability require a paid Metabase plan?
The supplied information does not describe high availability as limited to a paid plan, so confirm this with Metabase for your edition before you decide. Metabase's pricing page lists Open Source as free, Starter at $100 per month or $90 per month billed yearly with the first 5 users included, Pro at $575 per month or $517.50 per month billed yearly with the first 10 users included, and Enterprise priced by quote starting at $20,000 per year. The same page places SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing in Pro and Enterprise only. For many organizations, the plan decision depends on those features, while high availability is a separate architecture question. Confirm both points with Metabase.
How do Metabase upgrades change in a clustered setup?
In a cluster, you must plan upgrades around the application database migration lock. Metabase runs database migrations automatically when a new version starts, and the upgrade documentation recommends backing up the application database first. For major upgrades, it recommends reducing the cluster to a single node so that only one instance runs migrations. If you are upgrading from a version older than 40, move through each release in order rather than jumping directly. Plan a maintenance window that covers the single-node step, the upgrade and the return to full capacity. For rollback, Metabase documents restoring the pre-upgrade application database backup as the recommended path, with running the migrate down command using the newer JAR as the other option. Rehearse both before production.
How DeployOpen scopes, builds and hands over a Metabase cluster
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Metabase high availability, the work covers the application database, load balancer, health checks and upgrade procedure as one system, and engagements are fixed-scope with the scope agreed in writing before work starts.
How we scope
- The written scope lists the Metabase nodes, load balancer and PostgreSQL application database.
- We confirm the hosting environment, including cloud accounts, data centers or air-gapped networks, and who operates each layer.
- Engagements are fixed-scope, and ongoing support for the cluster can be added as a retainer.
How we build
- Provision PostgreSQL as the application database, since Metabase recommends it for production over the embedded H2 database.
- Run identical Metabase versions on every node behind the load balancer, with the same configuration and connection settings.
- Configure health checks against each node and test failover by stopping instances while sessions are active.
How we hand over
- Written runbook covering node addition, health check behavior, log locations and the cluster upgrade sequence.
- Upgrade procedure that backs up the application database first and reduces to one node for major upgrades.
- Rollback steps, tested in a non-production copy, covering restoration of the pre-upgrade application database backup.
How we support
- Retainer for ongoing support and upgrades to supported Metabase versions, once the cluster is live.
- Upgrade planning that checks each target version against the Metabase version support page before scheduling.
- Documentation updates after each change, so the runbook matches the cluster your team operates.
