Should you let Metabase host your BI instance or run it yourself?
Choose Metabase Cloud when you want Metabase to run the platform and your team wants to spend its time on dashboards rather than servers. Choose self-hosting when you need something Cloud does not allow: a community or custom database driver, your own fork of the code, air-gapped networks, or direct access to the application database. Metabase Cloud handles upgrades, backups, monitoring, multi-zone availability, SSL certificates, SMTP and SOC 2 Type 2 auditing, and instances stay on the latest version. It works only with officially supported databases (SQLite and H2 are excluded), and it runs in two regions, US West (Oregon) and Europe (Frankfurt). If your data residency rules fit one of those regions, Cloud is a reasonable default for a team without dedicated platform staff.
Several limits push teams to self-host. Cloud gives no access to the application database, does not allow you to customize the from address of emailed reports, and times out queries after 20 minutes. If your analysts run long warehouse queries, or your reporting depends on a custom driver or a specific sender address, confirm those needs against the Metabase Cloud limitations page before you commit. Also confirm where your data may be processed, because changing regions later requires updating firewall allowlists with the new region's IP addresses and causes downtime that the docs describe as usually under 30 minutes.
Self-hosting moves those tasks to your team. Expect to own upgrades, backups of the application database, monitoring, certificates, mail delivery and audit evidence, and to plan for the migration lock that Metabase documents for major upgrades. The move also works in the other direction: Metabase's Cloud versus self-hosting documentation notes that teams can start on Cloud and move to self-hosting later, so a Cloud pilot does not lock you in. Before you decide, confirm the database drivers you need, the query durations your analysts run, your residency requirements, and who on staff will carry the upkeep for the lifetime of the instance.
How Metabase Cloud and self-hosted Metabase differ on the factors that decide the choice
This table compares Metabase Cloud and self-hosted Metabase on operations, drivers, database access, query limits, regions, air-gapped use, forks and plan availability. Read each row as a question to ask your team: if a factor is a hard requirement for you, it settles the choice before cost does. Plan features listed as Pro or Enterprise apply to both models, so they do not separate the two options.
| Factor | Metabase Cloud | Self-hosted Metabase |
|---|---|---|
| Upgrades, backups and monitoring | Metabase handles them, and instances stay on the latest version | Your team performs upgrades, backups and monitoring |
| Multi-zone availability, SSL and SMTP | Handled by Metabase | Handled manually by your team |
| SOC 2 Type 2 auditing | Handled by Metabase | Manual; your team must produce its own evidence for assessors |
| Supported database drivers | Officially supported drivers only; community drivers not supported | Community or custom drivers can be used |
| Application database access | No access to the application database | Full access to the application database, PostgreSQL or MySQL recommended for production |
| From address on emailed reports | Cannot be customized | Can be configured in your own deployment |
| Query timeout | Queries time out after 20 minutes | Timeout is set by your deployment; confirm current settings in your environment |
| Hosting regions | US West (Oregon) and Europe (Frankfurt); region changes cause downtime and require allowlist updates | Wherever you run your infrastructure |
| Air-gapped operation | Not supported | Supported |
| Keeping a fork of the code | Not supported | Supported |
| Plan availability | Starter, Pro and Enterprise plans are available on Cloud | Open Source, plus Pro or Enterprise licenses for paid features |
Which Cloud limits push teams to self-host
The Cloud limitations docs name five constraints that most often send a team to self-hosting, and the first is the driver list. Metabase Cloud works only with officially supported databases and excludes SQLite and H2, and it does not support community drivers. If your warehouse, legacy system or internal database needs a community or custom driver, Cloud cannot connect to it, and self-hosting is the only route. Before you decide, confirm your exact database engine and version against Metabase's supported list, and check whether any source you need depends on a community driver. Also confirm whether the team that owns the source will accept a driver you maintain yourself.
The second and third limits concern the application database and emailed reports. Cloud gives no access to the application database, which holds your questions, dashboards, permissions and settings, so you cannot run your own backups, inspect data directly, or plan a migration on your own schedule. Cloud also does not let you change the from address of scheduled emails. If your security or messaging team requires reports to come from a specific domain that passes your mail authentication rules, that requirement alone can rule out Cloud. Ask your email team which sender domain and mail gateway the reports must use, and test a scheduled delivery on a trial instance before committing.
The fourth limit is the 20-minute query timeout. Any query that runs longer is stopped, which matters for heavy month-end aggregations, large exports and dashboards that join big tables. Measure the slowest questions your users run today, including the ones that power scheduled reports, and compare those runtimes with the 20-minute ceiling. If your slowest queries sit close to that limit or depend on database-side tuning you control, self-hosting gives you the same Metabase version with a runtime that does not depend on Cloud's limit. Confirm with Metabase whether the limit can change for your plan before you treat it as fixed.
How data location and compliance change with each model
Where your Metabase data sits, who controls the host and network path, and who produces compliance evidence all shift between Metabase Cloud and a self-hosted instance. The cards below separate what Metabase operates from what your team still owns, so you can check each point against your own assessment scope.
Choosing between the two regions
Metabase Cloud is hosted in US West (Oregon) or Europe (Frankfurt). If your data residency rules name a country or region, confirm with Metabase which region fits and whether the regional terms meet your requirement. Moving regions later causes downtime that usually lasts under 30 minutes, and every firewall allowlist must be updated with the new region's IP addresses, so plan that change with your network team.
Allowlist updates after a region move
Your database firewalls, VPN rules and SaaS connectors may only accept traffic from the IP addresses of the current region. A region change means new addresses must be added and, once cutover is verified, old rules removed. Record which systems hold these allowlists before you choose Cloud, because the update is a manual step on your side.
Who controls the host and network path
On Metabase Cloud, Metabase operates the servers, patching and backups, so your team controls the connection to your databases and user access inside the application. On a self-hosted instance, your team controls the host, the network segment, the TLS termination and the application database location. Decide which of these controls your assessment expects you to demonstrate directly.
Air-gapped operation needs self-hosting
Metabase's documentation lists running air-gapped as a reason to self-host, and Metabase Cloud does not support it. If your BI tool must run on a network with no outbound internet path, the self-hosted edition is the only option from this comparison. Confirm with Metabase which edition and features your air-gapped deployment needs, since paid features may apply.
SOC 2 Type 2 on Cloud, evidence still yours
Metabase's docs say Cloud handles SOC 2 Type 2 auditing, while self-hosting leaves that to you. A vendor report covers Metabase's controls, not your use of them. You still need to collect your own evidence, such as user access reviews, role assignments and data source configuration, for your assessment. Ask Metabase for the current report and confirm its scope before relying on it.
DeployOpen prepares, auditors attest
DeployOpen can plan and document the controls, configuration baselines and evidence collection for either model, whether the instance is on Metabase Cloud or in your own infrastructure. DeployOpen does not issue audit reports, attestations or certifications. Your independent auditor or certification body makes the determination, so confirm early which evidence they will accept for each model.
What your team runs in each model
This table lists the recurring operating tasks for a Metabase instance and shows who performs each one on Metabase Cloud versus a self-hosted deployment. Read it as a staffing question: the rows marked for your team are the work your engineers will own, and the version support windows set how often that work arrives.
| Operating task | Metabase Cloud | Self-hosted Metabase |
|---|---|---|
| Version upgrades | Metabase handles upgrades so instances stay on the latest version | Your team plans, schedules and runs each upgrade |
| Application database backups | Handled by Metabase Cloud; no direct access to the application database | Your team backs up the application database, ideally before every upgrade |
| Monitoring and uptime | Handled by Metabase Cloud | Your team sets up monitoring and responds to alerts |
| Multi-zone availability | Handled by Metabase Cloud | Your team designs and operates any multi-zone setup |
| SSL certificates and SMTP | Handled by Metabase Cloud, including the from address limit on emailed reports | Your team manages certificates, SMTP relay and the emailed report sender address |
| Major upgrades | Handled by Metabase Cloud | Migrations use a lock, so a cluster may need reducing to a single node first |
| Upgrading from versions older than 40 | Handled by Metabase Cloud | Upgrade release by release, one step at a time |
| Support windows | Metabase manages the version running on Cloud | LTS releases get 14 months of support; non-LTS releases usually reach end of life after 2 months |
| Metabase 64 LTS | Metabase Cloud runs the current release line for you | Metabase 64 is supported until 1 December 2027, so plan its upgrade path before then |
What Metabase Cloud and self-hosting actually cost
Metabase Cloud puts a published subscription price on hosting, while self-hosting moves the same work onto your payroll and infrastructure budget. On Metabase's pricing page, the Open Source edition is free, Starter is $100 per month ($90 per month billed yearly) with the first 5 users included, Pro is $575 per month ($517.50 per month billed yearly) with the first 10 users included, and Enterprise is priced by quote starting at $20,000 per year. Extra users cost $6 per month on Starter and $12 per month on Pro. Cloud is only offered on the Starter, Pro and Enterprise plans, so a Cloud team pays the subscription and its own internal time for data source setup, access design and dashboard governance. A self-hosted team pays for the hosting, the application database, email delivery, monitoring and upgrades itself, and it also pays for the Pro or Enterprise license if it needs SSO, row and column permissions or auditing. Confirm with Metabase which edition and user count each option requires for your headcount before you compare totals.
Transform runs are the cost line most teams overlook. The pricing page includes 1,000 transform runs on Starter and Pro and charges $0.01 per run after that, and it states that self-hosting gives unlimited transforms because they run on your own infrastructure. A transform schedule that runs often can therefore add a metered charge on Cloud that does not exist on your own servers, while on self-hosting the same runs consume compute and database capacity you already pay for. Ask Metabase to show your projected run count per month, the plan that includes it, and what happens to scheduled transforms when the included runs are used up. Ask whether Enterprise changes the run model, since the published terms address only Starter and Pro.
Build the quote request around what recurs. Subscription fees, extra user charges and any transform overage recur monthly or yearly. Self-hosting adds recurring costs for servers, backups, monitoring, certificates and staff time for upgrades, which Metabase's Cloud versus self-hosting docs list as manual tasks. Ask your partner or vendor to separate one-time work (installation, driver setup, SSO configuration, migration from H2 if you start on the embedded default) from the ongoing run cost. Ask who carries the upgrade routine, how many hours it takes per release cycle, and whether support is included. Confirm the Metabase support terms for each plan in writing, because the pricing page lists 3-day support for Starter and the details for other plans should come from the quote.
How to move from Metabase Cloud to self-hosting, and back
This sequence moves a Metabase instance from Metabase Cloud to a self-hosted deployment with its own application database, DNS, email and firewall rules, and it shows where moving back to Cloud runs into limits.
Confirm drivers, plan features and hosting duties
The platform or BI lead confirms that every data source you need is an officially supported driver, since Cloud does not run community drivers and self-hosting does. Confirm which paid features you rely on, such as SSO, row and column permissions or usage auditing, and which plan includes them. Your operations team takes ownership of upgrades, backups, monitoring, multi-zone availability, SSL certificates, SMTP and SOC 2 Type 2 auditing, which Metabase Cloud handles for you today. Done means a written list of drivers, plan features and named owners for each operational duty.
Export and plan the application database
Decide which application database the self-hosted instance will use. Metabase recommends PostgreSQL for production and also supports MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4. Metabase Cloud does not give you direct access to the application database, so ask Metabase support or your account contact how your questions, dashboards and settings will be exported, and confirm the export format before you commit to a cutover date. Done means you hold a tested export and a target database that meets the supported versions.
Install self-hosted Metabase with PostgreSQL or MySQL
The platform engineering team installs Metabase in your own infrastructure and points it at the chosen PostgreSQL or MySQL instance rather than the embedded H2 default, which Metabase ships for demos. Use the same version line as your Cloud instance so the data model matches. Run the one-time load-from-h2 command only if you are starting from an H2 file, and run it with the same Metabase version that last updated that file. Done means the instance starts, connects to the application database and shows your imported questions and dashboards in a test environment.
Rehearse the cutover in a test environment
Before any production change, the BI owner runs the full migration in a separate test environment that mirrors your data sources, users, SSO configuration and scheduled email reports. Check that every scheduled report sends, that single sign-on logins succeed and that group permissions match. Note that the from address of emailed reports cannot be customized on Metabase Cloud, so your SMTP configuration on self-hosting becomes a new point to verify. Done means a written checklist with each check marked as passed, and a rollback plan agreed with the owner of the Cloud account.
Cut over DNS and SMTP
During a planned window, the operations team points your public hostname at the self-hosted instance and switches email delivery to your own SMTP service. Confirm that SSL certificates are valid for the new endpoint, since Cloud no longer manages them. Keep the Cloud instance available until the new one has passed the checks from the rehearsal. Done means users reach the self-hosted URL, reports deliver from the new SMTP path and the Cloud instance is no longer serving traffic.
Update firewall allowlists
Your network team updates any firewall rules that allowed connections to or from Metabase Cloud so that the self-hosted instance can reach your data sources and mail relay. If your data sources accept only specific addresses, confirm the source addresses your self-hosted server uses. Verify each connection from the new host before retiring the old rules. Done means every data source and SMTP connection succeeds from the self-hosted server, and the rules that were added for Cloud are documented and removed.
Plan moving back to Cloud
If you later want to return to Metabase Cloud, check the Cloud limitations before you start. Cloud supports only officially supported databases, excluding SQLite and H2, does not support community drivers and gives no access to the application database. Queries time out after 20 minutes on Cloud, so confirm that your heaviest reports finish within that limit. Also note that switching hosting regions on Cloud, between US West (Oregon) and Europe (Frankfurt), causes downtime that usually lasts under 30 minutes and requires updating firewall allowlists with the new region's addresses. Done means you have a written list of any feature or driver that Cloud cannot run, and you have confirmed it with Metabase before a move back.
What buyers ask before choosing a Metabase hosting model
What does self-hosting Metabase cost in staff time?
Self-hosting moves upgrades, backups, monitoring, multi-zone availability, SSL certificates and SMTP setup from Metabase to your team, according to Metabase's Cloud versus self-hosting docs. Your recurring effort depends mainly on how often you upgrade. LTS releases are supported for 14 months and non-LTS releases usually reach end of life after 2 months, so a team that tracks non-LTS versions upgrades far more often. Upgrades run application database migrations automatically, but the docs recommend backing up the application database first and reducing a cluster to a single node for major upgrades. Costs rise with the number of instances, high availability requirements, custom drivers and air-gapped operation. Costs fall when you standardize on LTS releases and a managed PostgreSQL service. No staff-hour figure is published here, so ask your platform and data teams to estimate their hours for each recurring task.
Can our own team run self-hosted Metabase without outside help?
Yes, if your team already operates a Java application, PostgreSQL, certificates, SMTP and backups, and has someone who can read upgrade notes before each release. The backend is written in Clojure and Java and runs as a JAR, so the skills are familiar to many platform teams. The risky moments are upgrades and migrations, which need a tested backup, a single-node window for major upgrades and a rollback plan. Teams that lack this depth often hire help for the first deployment, then keep upgrades in-house. DeployOpen plans, implements, customizes, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Confirm your team's skills against the upgrade and backup steps before you decide.
How long does moving Metabase between Cloud and self-hosting take?
No duration for a full move between Metabase Cloud and a self-hosted instance is supplied here, so ask Metabase for its current guidance and ask your own team for an estimate. Metabase's docs say teams can start on Cloud and move to self-hosting later. The time usually depends on the application database size, the destination database, and whether you are moving off the embedded H2 database. Metabase's load-from-h2 command must run with the same Metabase version that last updated the H2 file. You also need to re-create data source connections, add any custom drivers that Cloud does not support, update firewall rules and confirm SMTP and certificates. A region change on Cloud is a different task: Metabase's change-region docs describe downtime that usually lasts under 30 minutes, and firewall allowlists must be updated with the new region's IP addresses.
What does Metabase Cloud not let us do?
Metabase's limitations page says Cloud works only with officially supported databases, excluding SQLite and H2, and does not support community drivers. It also gives no access to the application database, does not let you customize the from address of emailed reports, and times out queries after 20 minutes. Self-hosting is the option for keeping your own fork of the code, using community or custom database drivers, or running air-gapped. Cloud is also a plan decision: Metabase lists 1,000 transform runs on Starter and Pro, then charges 0.01 US dollars per run, and says self-hosting gives unlimited transforms because they run on your own infrastructure. Check your longest queries against the 20-minute limit and count the transform runs you expect each month before you choose.
Does Metabase Cloud handle SOC 2 evidence for our audit?
Metabase's docs list SOC 2 Type 2 auditing among the items handled on Metabase Cloud, while self-hosting makes that work manual. That covers the vendor-operated service, not your whole audit. Ask Metabase for its current SOC 2 report, its stated scope, and the period it covers, then map those controls against your own: user access, SSO and group configuration, change management for upgrades, backup and restore tests, and the data sources your analysts connect. Your auditor decides what evidence is sufficient for your environment. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies do. For a self-hosted deployment, DeployOpen can prepare systems, controls and evidence for a compliance assessment, which is a different service from the vendor's Cloud report.
Which Metabase release line should a self-hosted instance track?
Track an LTS line if your team cannot upgrade every couple of months. Metabase's version support page lists Metabase 64 as an LTS release published on 16 September 2026, with end of life on 1 December 2027. Metabase 65 was released on 12 October 2026. LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months, and every release receives bug fixes and security updates until its end-of-life date. Your choice shapes how often you schedule upgrades, how many test cycles you run and when you must plan the next major move. Confirm the current support window on Metabase's version support page before you commit, because end-of-life dates are the figures that govern your upgrade calendar.
What should we ask Metabase and DeployOpen in a quote?
Ask Metabase which plan and user count the quote covers. Metabase's pricing page lists Starter at 100 US dollars per month with the first 5 users included, Pro at 575 US dollars per month with the first 10 users included, and Enterprise priced by quote starting at 20,000 US dollars per year. Ask which features each plan includes, such as SSO, row and column permissions and auditing, and whether transform runs are counted. Ask DeployOpen for a written scope that names the installation, SSO and backup work, upgrade responsibilities, documentation, hardening, handover, and the support hours and response process for a retainer. DeployOpen does not publish a price list, and a quote follows from that written scope. Compare the two quotes on the same deliverables and the same recurring duties.
How DeployOpen scopes, delivers and supports self-hosted Metabase
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, that means taking on the duties Metabase Cloud would otherwise carry, such as upgrades, backups, monitoring and certificates, under a written scope agreed before work starts.
How we scope
- Inventory the databases, drivers and identity providers your Metabase must reach, including any community or custom drivers.
- Confirm the hosting target, network model and whether an air-gapped deployment is required before choosing an edition.
- Agree in writing which plan features, such as SSO or row and column permissions, are in scope and which are out.
How we build
- Deploy Metabase with PostgreSQL as the application database, moving off the embedded H2 default before any production use.
- Configure email delivery, SSL certificates, monitoring and backups, with the from address and SMTP settings set to your standards.
- Test upgrades, database migrations and a restore from backup in a non-production environment before go-live.
How we hand over
- Document the deployment, the upgrade routine and the application database backup and restore steps for your operations team.
- Walk your administrators through the Metabase version support windows so they can plan upgrades ahead of end-of-life dates.
- Deliver a written record of the Cloud-to-self-hosted duties now owned by your team, so responsibilities are clear from day one.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Retainers can cover release-by-release upgrades, migration checks and patch review against your change control process.
- Ask any provider to confirm response expectations and what the retainer excludes before signing, since these are set in writing.
