Our database schema is about to undergo a major structural change (including renaming schemas, tables, columns, and potentially some types).
We’re trying to anticipate the impact this will have on our Metabase environment (dashboards, saved questions, models, filters, etc.), and explore what tools or strategies are available within the open-source version to handle this migration smoothly.
Our main questions are:
What options exist in Metabase to manage schema changes (table/column renaming, dropped fields, etc.) ?
Are there recommended approaches or workflows to update field mappings without losing dashboards or breaking saved questions (SQL & Metabase queries) in Metabase ?
Is there any automation or API-based solution that could help with re-mapping new schema names to old ones?
If relevant, how does this differ from what’s available in Metabase Pro or Enterprise?
Any insights, or experiences from others who have gone through similar schema migrations would be greatly appreciated.
There is not good tooling for this that’s easily available. If you want to write it, it can be done with API and some cleverness, but it’s going to take time, most of it figuring out how to interact with the API as things like dashboard object formats are not well documented. Usually this means looking at what the UI does in the browser dev tools.
Depending on how many questions you have, and how complicated the migration is, it might be faster to just rebuild the affected questions.
Here’s what you’ll be contending with:
Questions written using the notebook editor whose tables are removed will fail to run, citing ‘Table xxx is inactive.’ These will have to be rebuilt as you can’t change the source table of a question in the UI without it resetting the notebook. Columns that are removed will disappear from the question, which could create errors if there are summarizations or custom columns that reference them.
SQL queries will need to be adjusted to the new schema.
Changes to data types of fields may require adjusting/reattaching filters.
If migrating Metabase is a huge undertaking because of the number of questions & dashboards, you may want to see if staging your schema migration is possible. Create database views that duplicate the function of the old tables so they don’t disappear from Metabase’s perspective. You can then rewrite questions to use the new tables at your leisure, and drop the views once the work is done. Metabase tracks tables by name and won’t notice if you swap a table for a view of the same name.
If you end up writing the tools, consider open-sourcing them. Since you will be 75% of the way there, extend the tools to allow cloning questions to a new database of identical schema of the previous one. That is a frequently requested function that will make you lots of friends.
A quick Google search found this tool, which might help, but test it on a spare instance first as it hasn’t been updated in a while:
As far as pro/enterprise… you’ll have to talk to Metabase Inc. I don’t know if they have any internal secret tools to make this any easier.
