Managed Metabase hosting means someone else runs the Metabase server, its application database, the backups and the upgrades, while your team builds dashboards on your ERP's data. The questions, dashboards and database logins stay yours. It suits companies that report from ERPNext, Odoo, Tally or Zoho and want the reports to keep working without an in-house person for the server. If you would rather do the server work yourself, our self-host Metabase guide covers the setup step by step.
Short answer
Managed Metabase hosting covers the server, Metabase's own application database (moved off the default H2 file), backups of that database, upgrades and logins. You keep the dashboards and the ERP data. Metabase Cloud is the least work of the three paths; self-hosting gives you the most control; a managed host sits between, on a server you can name.
I lead ERPNext, Frappe and open-source deployments at MithTech. Most of the Metabase work we see is not about charts. It is about the database Metabase keeps for itself, the upgrade nobody applied, and a reporting user that can read more than it should.
Honest take: Metabase is quick to start and easy to forget. The dashboards keep loading until the day the application database is lost or an upgrade fails, and then nobody knows who owns it.
What does managed Metabase hosting cover?
It covers everything between "the dashboard loads" and "the dashboard is right". That is the Metabase server itself, usually the official Docker image or the JAR on Java. It is the application database, which holds your saved work. It is the HTTPS proxy in front, the logins and groups, and the email settings that send subscriptions.
It also covers the jobs that come round on a calendar. Each Metabase upgrade runs any database migrations automatically on startup, so the application database must be backed up before it. A rollback, per Metabase's upgrade docs, means restoring that backup or running a migrate down command from the newer JAR. Someone has to know which one applies.
What it does not cover is your reporting logic. The questions, models and dashboards belong to the team that reads them. A host keeps them safe and running; it does not decide what "net sales" means. That work sits with analytics and BI.
Why move Metabase off H2 before anyone relies on it?
Because H2 is a demo database. Metabase ships with an embedded H2 file so you can try it in minutes, and its own docs say to avoid using that file in production. Without regular backups, they warn, the application database could get corrupted. The sooner you move, the better.
The move is documented and short, if you follow its rules:
Stop people creating content
Metabase's migration guide asks you to stop new work during the move. Anything saved after the copy is lost.
Back up the H2 file
With the JAR, stop Metabase and copy metabase.db.mv.db. With Docker, copy the file out of the container first; it lives inside it.
Create an empty target database
PostgreSQL is Metabase's recommended application database; MySQL and MariaDB are also supported. The command expects a brand-new, empty database.
Run load-from-h2 on the same version
Set the target database's environment variables and run load-from-h2 with the path to the H2 file. Use the same Metabase version throughout the move.
Start Metabase normally and check
Start it against the new database, open a few dashboards, and keep the H2 copy until you are sure everything came across.
You can check which application database an instance uses: Metabase's docs point to GET /api/bug-reporting/details, and if application-database is not postgres or mysql, you are on H2. The self-host Metabase guide has the MB_DB_* variables for a fresh install.
How should Metabase connect to your ERP safely?
With a read-only user, on a reporting copy, never with the ERP's own admin login. Metabase's docs recommend a dedicated metabase database user with read-only access, given connect rights and SELECT on only the schemas or tables you report on. That one rule means a dashboard can never change an ERP record.
The second rule is ours: report from a copy, not from the database your accounts team is posting into. Heavy dashboard queries at month-end compete with live work. A replica or a nightly reporting copy keeps the two apart, and it gives you a place to add views that make the ERP's tables readable.
How you get that copy depends on the ERP. We support ERPNext, Tally, SAP Business One, Zoho and Odoo, and they differ here:
ERPNext
Frappe, and so ERPNext, runs on MariaDB, and Metabase has an official MariaDB driver. Connect a read-only user to a replica or a reporting copy of the site database. For reports inside ERPNext itself, see ERPNext dashboards and reports.
Odoo
Odoo uses PostgreSQL, which Metabase also connects to with an official driver. The same pattern applies: a read-only role on a replica or a copy, not the production database.
Tally and Zoho
These are reached through exports or their APIs rather than a database you query directly. TallyPrime offers XML and JSON over HTTP and file exports; Zoho Books has a REST API. Load the data on a schedule into a separate reporting database, and point Metabase at that.
For a wider look at what Metabase and Superset can and cannot replace, see open-source Power BI alternatives.
Self-hosted, Metabase Cloud or run for you: how do they compare?
All three run the same Metabase. The difference is who does the server work, and where the server sits. Be fair to Metabase Cloud: it is the least work. Its pricing page says Metabase handles setup, backups and upgrades, and its upgrade docs say Cloud instances are upgraded automatically with each release. If your data can live where Cloud hosts it, that is hard to beat.
| Run for you | |||
|---|---|---|---|
| Who runs the server | Your team | Metabase | A managed host |
| Application database | You move it off H2 and back it up | Handled by Metabase | The host moves it off H2, backs it up and tests a restore |
| Upgrades | You read the notes, back up, upgrade | Automatic with each release | The host, ideally tried on a copy first |
| Where it runs | Any server you choose | The regions Metabase offers | A server you can name, in your cloud account or the host's |
| Reaching your ERP | Your network, your rules | From Metabase's IP addresses, let through your firewall | From that server, inside your network if it sits in your cloud account |
| Cost | The server and your team's time | A Cloud plan on metabase.com/pricing | A host's fee plus the server |
Two facts worth checking before you choose Cloud. Its change-region page lists US West (Oregon) and Europe (Frankfurt) as hosting regions (read 29 October 2026). And Cloud connects from Metabase's own IP addresses, which the same page says to add to your firewall's allowlist, so a reporting copy inside a private network needs an opening for them. For plans and what each includes, read Metabase's pricing page directly; we do not quote it here, because it changes.
For how the same three paths look for the ERP itself, see who runs ERPNext after go-live.
What do you keep, and how do you leave?
You keep the application database, because everything you built lives in it: questions, dashboards, models, collections, users and settings. Your ERP data is separate and stays in the ERP. Whichever path you take, the exit is the same file moving to a new home.
- Self-hosted: back up the application database with that database's own tools (Metabase's backup docs point to PostgreSQL's for a PostgreSQL app database) and restore it under the same Metabase version elsewhere.
- Metabase Cloud: Metabase's docs say you cannot generate the snapshot yourself. Its Success Engineering team sends an H2 snapshot of the application database, which you load with
load-from-h2into an empty database on the same major version. Moving in works the other way: from Metabase 50, you start it from the admin settings and the instance is read-only while the copy is taken. - Run for you: get the exit in writing before you start. If the server sits in your own cloud account, it is already yours; if it sits in the host's, you need a full backup of the application database and the settings.
Test the exit once, early. Restore the application database onto a spare server and open a dashboard. An untested backup is a guess.
Should you run Metabase yourself, or have it run for you?
Run it yourself if someone on your team will apply upgrades, back up the application database before each one, and test a restore now and then. Choose Metabase Cloud if you want the least work and its hosting regions suit you. Have it run for you if the dashboards feed daily decisions, the instance sits next to your ERP data, and nobody wants to own the server.
Do it yourself if
You have someone at home with Docker or Java, PostgreSQL and a reverse proxy, a spare server to test restores on, and viewers who can wait a few hours if the dashboards are down.
Have it run for you if
Managers read these dashboards every day, the instance reaches your ERP or a reporting copy of it, the data has to stay in a region you pick, or nobody wants to read release notes before each upgrade.
Under managed hosting we run Metabase on one named server in your cloud account or ours, not a shared pool: nightly backups copied off the server, one restored on a schedule, every upgrade tried on a copy first, and the master login stays yours. It is a monthly fee for running it plus the server, quoted in writing after a call. We pick the region with you, and an Indian region is the usual choice for Indian companies, with backups going to a second location you approve. If you leave, in your account the server is already yours; on ours you get a full backup, the code and the settings. The self-hosting cost comparator helps you set that against a hosted BI bill.
Frequently asked questions
+Is Metabase Cloud better than self-hosting?
For the least work, yes: Metabase runs the server, the backups and the upgrades. Self-hosting, or having it run for you, makes sense when the data must sit in a region Cloud does not list, when the database Metabase reads is inside a private network, or when you want the instance on a server you can name.
+Can Metabase connect to ERPNext?
Yes. ERPNext runs on MariaDB, and Metabase has an official MariaDB driver. Connect a dedicated read-only user to a replica or reporting copy of the site database, not the live one. Tally and Zoho need their data exported or pulled through an API into a reporting database first.
+Where does Metabase store dashboards?
In its application database, separate from the databases you analyse. It holds questions, dashboards, collections, users and settings. Back it up before every upgrade, and keep the backup off the server. On the default H2 file, stop Metabase before copying it.
+What happens to my dashboards if I leave Metabase Cloud?
Metabase's Success Engineering team sends you an H2 snapshot of the application database. You load it into an empty self-hosted database with load-from-h2, using the same major version of Metabase, then start Metabase normally. Your ERP data was never in Cloud's application database.
+Does upgrading Metabase change the database?
Yes. Metabase runs any needed migrations automatically on startup, so back up the application database first. To go back, restore that backup, or run migrate down from the newer Metabase JAR. On a version older than 40, step up release by release to the latest 40.x first.
Prefer to explore first? See the analytics and BI page for how we build the reports themselves.
Comments & ratings
No comments yet. Start a new discussion.
Manoj · Published on 29 October 2026
Worked with us? Leave a Google review