Running Metabase in production: upgrades, access and performance
Metabase is the window the whole business looks at the data through, which makes it easy to neglect and expensive to get wrong. Here is how I kept it current, locked down its access to least privilege, and turned a timeout-prone dashboard into a fast one.
A BI tool quietly accumulates risk. It sits on powerful database credentials, its dashboards get slower as data grows, and its version drifts behind until an upgrade feels scary. I treated keeping Metabase healthy as three ongoing jobs: stay current, hold least privilege, and keep queries fast.
Stay current, environment by environment
I kept Metabase on supported versions rather than letting it rot, upgrading through several minor releases across environments and planning each bump instead of jumping blind. Routine, but it is the routine that stops a one-day upgrade from becoming a one-week one.
Least privilege: a BI tool should only read
Metabase connects to the databases it visualizes, and it is tempting to hand it a broad user because that "just works". That broad user is also a standing risk: a reporting tool with write access to source data is an incident waiting to happen. I replaced the broad database users with a dedicated read-only user, so the BI layer can query everything it needs and change nothing. A visualization tool has no business being able to write.
Keep production out of the blast radius
Heavy analytical queries and live production traffic do not belong on the same database node. I mapped every data source Metabase was reading from and found queries landing on the primary, competing with the application. I routed those reads to a dedicated analytics replica instead, so a slow dashboard can never slow down the product.
Kill the slow dashboard with the right index
One dashboard was timing out with 524s under load. The cause was the classic one: a query doing a lot of work with no supporting index. Adding the right composite index turned a timeout into a fast response. Databases reward the index that matches the query, and punish its absence exactly when traffic is highest.
Also: trust the data, not just the tool
A separate but related job is data freshness. When a dashboard quietly stopped updating for one downstream integration, the tool looked fine; the data had gone stale upstream. Operating a BI platform well means watching the pipeline into it, not only the service itself, because a confidently-wrong dashboard is worse than a broken one.
What I would tell someone running a BI tool
- Give it a read-only user. A reporting tool should never be able to write to source data.
- Point analytical reads at a replica. Keep heavy dashboards off the node that serves the product.
- Index for the query. A timing-out dashboard is usually a missing composite index, not a tool problem.
- Watch the data in, not just the service. A stale dashboard that still renders is the quiet failure mode.
- Upgrade on a schedule. Staying a few minors behind is cheaper than catching up by years.