How do you handle schema changes breaking dashboards?

Get Help
1

Hi everyone,

I'm curious how other teams handle one of the most frustrating parts of using Metabase at scale: schema changes breaking questions and dashboards.

Our team is constantly running into situations where:

  • Renaming a column breaks dozens of questions that reference it
  • Dropping a deprecated table cascades into dashboard failures
  • Refactoring database schemas requires manually hunting down and updating every affected query

A few questions:

  1. How do you currently handle this? Do you have processes or tooling in place?
  2. How much time does your team spend fixing broken queries after schema changes?
  3. Have you found any workarounds? (Views as abstraction layers, naming conventions, migration scripts, etc.)
  4. Does this pain point ever make you hesitant to clean up or refactor your database schema?
  5. What would an ideal solution look like for you?

For context, we're a ~50 person company with about 200 dashboards and it feels like every database migration creates hours of cleanup work tracking down what broke.

Would love to hear how others are dealing with this!

2

This is an organizational issue. Mainly, the people who maintain the BI tools (like Metabase) are not stakeholders in the schema design & evolution process and are left out in the cold when production schema changes. Its usually a symptom of issues in change management & project management.

A lot of organizations solve this by having a separate reporting database and an ETL process that translates one to the other. Only ETL has to be updated when production schema changes. If a schema change negatively impacts reporting (i.e., method of calculating KPI changes) then all the stakeholders are brought together on the project to ensure new data flows correctly. This works if reporting data doesn’t have to be real time.

1 Like
3

Got it, thanks for the response. We actually do use dbt, but people inevitably end up creating reports against raw production tables when they need something quick. We also have legacy reports from before we adopted dbt that still reference production tables directly.

Sounds like the solution is enforcing queries against dbt models only and migrating our existing reports. Appreciate the input!

4

We’ve found that the best approach is to create a specific schema for Metabase that only contains views. Then grant the metabase account rights to see just that schema.

That avoids all the problems of Metabase scanning all your database and people writing question directly against tables.

1 Like