Current engineering frustation using Metabase (semantic layer, versioning, denormalized tables, agentic coding)

Hello
My company recently decided to migrate all our BI dashboards to Metabase.
We are using a dbt for layering our data sources into marts with fact and dim tables.
But I’m facing a lot of frustration while deciding the implementation of our dashboard for reusability

For introduction, I’m a data engineer with heavy software engineering background (version control, clean code, TDD) and I have less experience with visualization tools and it’s the first time I’m responsible of managing it more than just creating few dashboard for IT teams.

1 - Metabase is not compatible with dbt semantic layer, so we are not sure if the semantic should live in dbt (there are few, not well maintained dbt to metabase git project, but at least it lives in our git repo and we can leverage MR and review) or in Metabase (but missing clean version control)
Metabase version control does exist but :

  • I thinks it’s only compatible with collections and not the metadata/semantic part
  • It also requires at least two paid env for testing/branch while some other BI tools have a dev mode
  • We tried to edit code directly on a branch in the repo, but we were not very successful

2 - Let’s say we adopted the semantic in Metabase option. We should now organize our models, questions and metrics. I have tested to create sql models, but once you saved your model, metabase add a wrapper around your query (AS "__mb_source" and double the size of your queries making all your sql models harder to read and bigger for no true reason IMO).

Then I tried to leverage native query builder, so I do the joins there to keep it clean, save it as a model and … it’s flatten as sql by metabase and I can’t edit or review it cleanly in the query builder

Finally I tested to create question than I never turn into a model (there the editor keep the the visual join once saved).
So I’m not sure why I should use models instead of “table” questions, seems there are only downside for my usecase

I’m almost tempted to write the denormalized model directly in dbt and just have a thin select * from in Metabase to avoid doing any join there

3 - I’ve the same question for metrics vs single aggregated number question ? Not sure where the difference truly lives

4 - Even with versioning and serialization, agentic coding (claude, codex, etc) is not working very well with our Metabase git repo. With the shift in development practices we are currently seeing in software engineering, I see it as a real blocker to be stuck with low code/no code tools where you can’t leverage building dashboard or question directly in yml with coding agent.

There are some frustration statements here, I’m probably doing some parts wrong on my side too.
I’m open to any feedback or guidance about how to improve our Metabase working flow

Thanks a lot !

Hey @Guillaume-gg, we saw your post and we would love to meet with you next week, is that possible? We would like to validate a few ideas with you. Please write to help at metabase dot com

Thx for the answer
I’ve just sent an email to help @ metabase . com