Pro ยท Lesson 9 of 9
Back up Metabase's own database, upgrade on purpose, and treat slow charts as warehouse queries.
Sign in to save your place.
Production Metabase is a reception desk you cannot afford to lose. The filing cabinet is the application database. Copy that cabinet before you change the desk. The warehouse can be healthy while the desk has forgotten every saved chart.
Back up the application database on a schedule, and take an extra backup before every upgrade. Metabase migrates that database when a new version starts. If the migration fails, the backup is how you return. For Docker, pin the image tag you intend to run. Pull the new tag only after the backup has finished and you know where the file or dump is.
Put HTTPS in front of Metabase with your reverse proxy. Set a real admin password and store it in your password manager. Health is GET /api/health. A load balancer can use that path. It does not prove the warehouse connection is fast. It proves the application process answered.
# Application database, not the warehouse.
pg_dump -h metabase-db.internal -U metabase -Fc -f metabase-app.dump metabase
# Then move the container to the tag you just backed up for.
docker pull metabase/metabase:LATEST_YOU_CHOSESlow charts are usually slow warehouse queries. Read the query Metabase sent, then index or model that query in the warehouse. Caching absorbs repeated views. It does not fix a question that scans a year of raw events for a single number. Move that scan into a model or a warehouse table that is already aggregated.
Connection pools in the database settings limit how many warehouse sessions Metabase opens. Raising the pool because a dashboard is slow often makes the warehouse busier. Cap it, and fix the question.
Set MB_ENCRYPTION_SECRET_KEY on instances that encrypt stored credentials, and keep that key with the backups. Losing the key can make stored database passwords unreadable even when the dump is fine. Do not commit the key, the embedding secret, or the admin password to the repository that deploys Metabase.
| Failure | What still works | What you restore |
|---|---|---|
| Warehouse outage | Saved questions, as definitions | The warehouse, separately |
| Lost app database | The warehouse rows | The Metabase dump |
| Bad upgrade | The previous image, if you kept it | The pre-upgrade dump |
Upgrade in this order every time and you can always go back.
Step 1 of 3Back up the application database first. Upgrades change its structure, and the only reliable way back is restoring that backup.
pg_dump -Fc metabase > metabase-before-upgrade.dumpStep 2 of 3Replace the container with the new version. On start-up Metabase migrates the application database.
docker pull metabase/metabase:latest && docker compose up -dStep 3 of 3Wait until the health endpoint reports ok, then open a few key dashboards before telling users.
curl https://metabase.example.com/api/health # {"status":"ok"}Write down the image tag, the app database host, who holds the encryption key, and when the last dump was restored in a drill. A backup you have never restored is a hope. The next lesson is not another Metabase page. Go use a model and a dashboard on data you are allowed to read.
Checked against vendor documentation in October 2026. Screens and plan names still change, so confirm the control in your own instance.