> In our experience, the BI layer is the weakest part of the modern data stack. The BI layer has a poor developer experience, and decision makers don’t really like the outputs they get Totally agree, very interested in trying this out. FWIW I've tried and been frustrated by Looker, Metabase, PowerBI, Superset, Redash. I do think that while dbt does a great job with dimensional modelling, the BI layer is still require…
You are exactly right, right now this is pure front-end. That's intentional, and there's a lot that we like about that approach, especially in light of the success of dbt.
We think dbt fundamentally changes what is needed from a BI tool and that vendors who are maintaining really heavy built-in data transformation layers will basically be wasting resources over the coming years. The approach of modelling in your data warehouse is just so much more sensible, that we think it's a really a good thing to bet on.
That said, having some form of metric modelling in your BI tool is really nice -- it helps you keep your queries dry, and makes it simpler to roll out changes. If we were to build something here, I think it would be very lightweight -- a config that basically let you define re-usable sql snippets, and maybe some constraints on them.
On the other hand, there are A LOT of startups building metrics layers, which look great. Usually these expose an API endpoint, and some sort SQL interface. We'd be just as happy to plug into one of those SQL interfaces and call it a day. I just wish one of those was open source, since the metrics layer is such a choke-hold on your data operation.
Maybe someone will build the 'dbt of metrics layers'. That would be great for the ecosystem. Maybe dbt will do it themselves. I think there's probably something interesting they could do there by treating stored procedures as materialization targets.