Metabase

Last reviewed Aug 26, 2026 · 860 words

Metabase starts in one command and stores every dashboard, question and user you create in an embedded H2 database file that Metabase's own documentation tells you not to use in production. Switch that application database to PostgreSQL on day one, before you have built anything worth losing, and the rest of running Metabase is pleasant. Wait six months and you will do the same migration on a Sunday under duress.

There are two databases, and confusing them costs people their dashboards

The application database holds Metabase's own state: users, saved questions, dashboards, permissions. The data source is whatever you point Metabase at to ask questions of. Newcomers back up the second and forget the first, or run the container without a volume and lose the H2 file on the next docker compose up. Make the split explicit:

services:
  metabase:
    image: metabase/metabase:latest
    ports:
      - "3000:3000"
    environment:
      - MB_DB_TYPE=postgres
      - MB_DB_HOST=metabase-db
      - MB_DB_PORT=5432
      - MB_DB_DBNAME=metabase
      - MB_DB_USER=metabase
      - MB_DB_PASS=change-me
      - JAVA_OPTS=-Xmx2g
    depends_on:
      - metabase-db
    restart: unless-stopped
  metabase-db:
    image: postgres:16
    environment:
      - POSTGRES_DB=metabase
      - POSTGRES_USER=metabase
      - POSTGRES_PASSWORD=change-me
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    restart: unless-stopped

If you already have an H2 install, Metabase ships a load-from-h2 command that copies everything into the new PostgreSQL database in one pass; run it with the app stopped and keep the old .mv.db file until you have logged into the new instance. From then on, backing up Metabase is a nightly pg_dump of a database that is usually under 100 MB, and the argument in Postgres for everything applies here more than almost anywhere.

Plan on 2 GB, and tell the JVM so

Metabase is a Clojure application on the JVM, and the catalogue's 2,048 MB minimum is real: the container idles around 1 GB and climbs when several people open dashboards at once. The JAVA_OPTS=-Xmx2g line above caps the heap so a burst of queries produces slow dashboards rather than a container the kernel kills. On a 4 GB box, give Metabase 2 GB and the PostgreSQL sidecar the rest; on an 8 GB box, -Xmx4g buys noticeably smoother concurrent use. Do not run it on a 2 GB Raspberry Pi and expect a good week.

Connect with a user that cannot write

Metabase runs whatever SQL the native query editor is given, using the credentials you supplied. Create a dedicated read-only role in the source database and connect with that:

CREATE ROLE metabase_ro LOGIN PASSWORD 'change-me';
GRANT CONNECT ON DATABASE shop TO metabase_ro;
GRANT USAGE ON SCHEMA public TO metabase_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO metabase_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO metabase_ro;

Then a colleague who pastes a DELETE into the SQL editor at 5 pm on a Friday gets a permission error instead of a career moment. The same logic argues for pointing Metabase at a read replica when the production database is busy; the sync and fingerprinting scans it runs on a schedule are modest but not free.

What the free edition includes, and what it does not

For a homelab or a small company the free column is the product. The paid line is drawn at the features enterprises need to hand Metabase to customers or hundreds of staff, which is a fairer split than most open-core tools manage. Pricing changes; check metabase.com rather than trusting a number written here.

Where it is the wrong tool

Metabase is for questions about rows in a database: sales by region, sign-ups by week, orders stuck in a state. It is not a metrics system. Time-series from Prometheus, host dashboards and alerting on latency belong in Grafana, and making Metabase draw CPU graphs ends badly. Website traffic belongs in Plausible or the other tools in the analytics category. At the heavier end, Apache Superset offers more chart types and finer SQL control at the cost of a much larger install and a steeper curve for non-technical users. Metabase's whole pitch is that the person in accounts can build the question themselves, and that pitch holds.

What I'd do

The compose file above, PostgreSQL for the application database from the first boot, a 4 GB box with the heap capped at 2 GB, read-only credentials for every data source, nightly pg_dump off the machine. Build a handful of models early, which are curated views of ugly tables, so everyone else builds questions on those instead of raw schemas. That configuration has run for years at small companies without anyone thinking about it, which is the highest compliment I have for business software.