Metabase

List every database connection before deployment. For each, name the owner, host or network path, database role, schemas or tables allowed, expected query audience, and whether it points at a reporting replica or an operational system. Give Metabase credentials the least access that supports intended questions. A shared administrator credential turns an analytics application into an uncontrolled route to production data.

Where reporting queries could affect live workloads, use a suitable replica, warehouse, or purpose-built reporting store. Test expensive likely dashboard filters and exports. Check connection limits and timeouts with the database team. A dashboard that runs quickly for one user can cause harm when a whole team opens it at the start of a working day.

Data definitions should travel with the connection. Give datasets human names, document joins and refresh expectations, and identify who can approve a change. An illustrative metric called active customer needs an agreed time window, exclusion rules, and source. Without them, two saved questions can return different totals while both look convincing.

Map authentication to the way people already join and leave the organisation. Use the current Metabase documentation to select the right integration rather than inventing a local account process. Retain a controlled administrator recovery route, protect it carefully, and test offboarding before someone leaves with broad access.

Permissions have layers. A person may see a collection, run a saved question, query a database, or access a row and column through a chosen data model. Review them together. Sensitive-data policy often depends on the last layer. Hiding a dashboard folder does not make an unrestricted database query safe.

Collections need an editorial owner. Separate working drafts from reviewed shared material, keep obsolete dashboards out of default navigation, and set review dates for high-impact questions. This avoids a familiar failure: a broken or superseded dashboard stays bookmarked and becomes the unofficial answer because nobody knows who owns it.

Production operation includes application configuration, the application database, connection secrets, mail where used, logs, backups, and version changes. Keep configuration in a controlled deployment method and passwords outside screenshots and ad hoc shell history. Monitor availability from a user perspective as well as process health: a running web process is not useful if the metadata store or primary data connection is unavailable.

Back up the Metabase application database on a schedule that matches the value of saved work. Restore it into an isolated environment and confirm that users, collections, permissions, and a known dashboard return. Document what is outside that restore, such as source-system data or a separately managed identity provider. Recovery questions are much easier when those lines are clear.

Read release-specific upgrade guidance before changing versions. Capture a backup, identify database migrations, test representative dashboards and authentication, and arrange a rollback decision. If the application serves operational reporting, tell dashboard owners about maintenance windows. Treat a major metric-model change with the care given to an application interface change.