Mitigating Maintenance Overhead with Metabase Queries During DB Migrations

Get Help
1

Hello all,

I've been leveraging Metabase to serve our business with direct queries to our database. Currently, Metabase is connected to a read-only version of our database. However, as we undergo changes in our database structure and execute DB migrations, we're encountering an issue: we need to adjust numerous queries that reference the affected database entities.

To give some context, we've made a significant number of queries, which means any change in our DB structure results in a heavy maintenance overhead to update those queries in Metabase.

I'm aware of the 'models' feature in Metabase, but from my experience, filtering within those doesn't seem to be as efficient as I'd hoped.

I'm reaching out to see if anyone has:

  1. Experienced similar challenges and how you've dealt with them.
  2. Any recommendations on how to structure or manage Metabase queries to minimize the maintenance required when the underlying DB undergoes changes.
  3. Tips or best practices with the 'models' in Metabase or any other feature I might be under-utilizing.

Any insights or advice would be greatly appreciated. Thank you in advance!

2

Views, views and more views. Then you can just change the views on the database rather than the model in Metabase.

1 Like
3

Do you mean a new db, that converts my original entities into new entities that are specificly for the business case, if so isn't keeping the view in sync with the original db to much work?

4

No, I mean views on your existing database. Typically in a different schema for ease of use.

Can be as simple as select a,b,c from X. If the datatype of 'a' changes, you can just cast it back in the view.

You can simplify the schema at the same time.
You only have to change the views in one place, not in every question/dashboard that references them.
I never use Metabase with the base tables of a database.

1 Like
5

Sounds good. Thank you very much.