Metabase Cloud vs. Self-Hosted: How to Choose

The choice between Metabase Cloud and self-hosted Metabase comes down to three variables: how much operational overhead your team can absorb, where your data lives, and what your compliance requirements are. Both options run the same Metabase application and support the same features at a given license tier. The difference is entirely in who manages the infrastructure.

---

What's the Same

Before getting into differences, it's worth being explicit about what doesn't change between deployment models:

The Metabase application itself — same UI, same API, same features

Feature availability by plan tier (Pro features require Pro regardless of deployment model)

Query execution behavior — Metabase connects to your databases and runs queries against them in both models

The embedding API — signed embedding, row-level security, and JWT auth work identically

Data storage model — Metabase stores configuration (dashboards, questions, users) in its application database; your analytics data stays in your own databases

---

Metabase Cloud

Metabase Cloud is a fully managed hosted service. Anthropic runs the infrastructure, handles upgrades, monitors uptime, and manages the application database. You pay a monthly fee and interact with Metabase entirely through the browser.

What Metabase Manages for You

Infrastructure provisioning — servers, containers, load balancers

Application database — the PostgreSQL database that stores Metabase's configuration

Upgrades — new versions are deployed automatically on a rolling schedule

Backups — application data is backed up automatically

Uptime monitoring — Metabase's SRE team handles incident response

SSL/TLS — HTTPS is configured automatically at your *.metabaseapp.com subdomain or custom domain

What You Still Manage

Your data sources — your databases, warehouses, and data pipelines are entirely yours

Network access — you need to allow Metabase Cloud's IP ranges to connect to your databases

User management — creating users, configuring groups, and managing permissions

Dashboard and question content — all the analytics work itself

Metabase Cloud Pricing

Cloud pricing is per-user per-month, with different tiers for Pro and Enterprise. The Pro tier includes signed embedding, SSO, and data sandboxing — the features most commonly needed for production deployments. Current pricing is available at metabase.com/pricing.

When to Choose Cloud

Choose Metabase Cloud if:

Your team doesn't have the operational capacity to manage a self-hosted service

You're a small team where DevOps time is a scarce resource

You need to get started quickly without setting up infrastructure

Your data lives in a cloud-hosted database that can accept connections from Metabase's IP ranges

Compliance requirements don't prevent you from using a third-party managed service

---

Self-Hosted Metabase

Self-hosted Metabase means you run the application on your own infrastructure — a VM, a Kubernetes cluster, Docker Compose on a dedicated server, or any container-based deployment. You're responsible for the infrastructure, upgrades, backups, and uptime.

What You Manage

Compute — the server or container running Metabase

Application database — the PostgreSQL instance storing Metabase's configuration

Upgrades — pulling new Docker image versions, applying them, and verifying migrations succeeded

Backups — backing up the application database on a schedule

Uptime — monitoring, alerting, and incident response

TLS — configuring HTTPS through a reverse proxy or load balancer

Scaling — adding capacity when usage grows

Open Source Edition

The open-source edition of Metabase is available only as self-hosted. It includes the core features — query builder, SQL editor, dashboards, basic permissions — with no license fee. You pay only for the infrastructure you run it on.

For teams with straightforward internal analytics needs and no embedding requirements, the open-source edition on a small VM or cloud container service may be all that's needed.

Pro and Enterprise (Self-Hosted)

The Pro and Enterprise editions are available as self-hosted deployments with a paid license. You run the metabase/metabase-enterprise Docker image and apply your license key via the Admin panel or MB_PREMIUM_EMBEDDING_TOKEN environment variable.

Self-hosted Pro gives you signed embedding, SSO, data sandboxing, and audit logging — all running on infrastructure you control.

When to Choose Self-Hosted

Choose self-hosted if:

You have strict data residency requirements — your data and Metabase must stay within a specific region or VPC

Compliance requirements (HIPAA, SOC 2, FedRAMP) require you to control the full stack

You need to keep Metabase within your private network, unreachable from the public internet

You have existing DevOps infrastructure (Kubernetes, Terraform, CI/CD pipelines) and absorbing Metabase into it is low overhead

You're already running the open-source edition and it meets your needs

Cost predictability matters — self-hosted costs scale with infrastructure, not per-seat pricing

---

Head-to-Head Comparison

Dimension	Metabase Cloud	Self-Hosted
Setup time	Minutes	30 minutes to a few hours
Ongoing ops burden	None	Moderate
Upgrades	Automatic	Manual (Docker image pull)
Uptime SLA	Metabase provides	You provide
Data residency control	Limited	Full control
Network isolation	No (public internet)	Yes (private VPC)
Cost model	Per-user per-month	Infrastructure cost + license
Open-source option	No	Yes
Custom domain	Yes	Yes
HIPAA / regulated industries	Check with Metabase	Yes, if your infra is compliant

---

Common Decision Scenarios

Startup or Small Team

A 10-person startup with a PostgreSQL production database on RDS and no dedicated DevOps engineer should almost certainly start with Metabase Cloud. The per-seat cost is low at small scale, setup is instant, and no one needs to spend time managing infrastructure.

SaaS Company with Embedded Analytics

A SaaS product embedding Metabase dashboards for customers needs to evaluate carefully. Cloud works well here — embedding is fully supported, and the managed infrastructure means no operational overhead. However, if the product has enterprise customers with strict data residency or network isolation requirements, self-hosted gives you more control over where Metabase runs and who can reach it.

Enterprise with Compliance Requirements

Organizations with HIPAA, FedRAMP, or strict data residency requirements typically choose self-hosted. Running Metabase inside your own VPC ensures that analytics traffic never crosses a third-party network and that the full audit trail stays within your control.

Team with Existing Kubernetes Infrastructure

If your team already runs services on Kubernetes and has Helm-based deployment patterns in place, adding Metabase as a self-hosted service is low friction. The operational overhead is absorbed into existing workflows.

---

Migration Between Deployment Models

Migrating from Cloud to self-hosted (or vice versa) is possible but requires effort. Metabase doesn't provide an automated migration tool. The typical migration path involves:

Exporting serialized content (dashboards, questions, collections) using Metabase's serialization feature (Pro/Enterprise)

Importing the serialized content into the destination instance

Recreating database connections and user accounts

Reconfiguring SSO and permission groups

For this reason, it's worth getting the deployment model right early. For teams that anticipate compliance or data residency requirements, starting self-hosted is lower risk than migrating later.

---

Hybrid Approaches

Some organizations run a self-hosted Metabase instance for their primary internal analytics but use Metabase Cloud for a separate embedded analytics deployment that serves customers. This is a legitimate pattern but adds operational complexity — you're now managing two instances with separate user bases and configurations.

More commonly, teams start on Cloud and migrate to self-hosted as compliance or scale requirements emerge.

---

Summary

Metabase Cloud is the right default for teams that want analytics without infrastructure work. Self-hosted is the right choice for teams with compliance requirements, data residency constraints, or existing DevOps capacity to manage the deployment. Both run the same software and support the same features. The decision is purely operational — who manages the infrastructure and where it runs.

For most development teams building embedded analytics, either model works. If in doubt, start with Cloud. You can always migrate to self-hosted later, and starting with Cloud doesn't lock you into any proprietary data format or storage model.