My sql is so much more readable with common logic extracted into ephmeral models.Sounds great. My concern though with DBT is the cognitive overhead and just plain ... weirdness and clunkiness it seems to introduce as a cost to obtaining benefits like these.
For example if we look at their own documentation:
When using the view materialization, your model is rebuilt as a view on each run, via a create view as statement.
https://docs.getdbt.com/docs/build/materializations
Now, isn't your reaction, upon reading this, some version of: "Whaaat? Views are not materializations - by definition, they are essentially the opposite of materializations."
And yet here the DBT documentation is describing the results of plain old "create view" statements as materializations.
And then we're not getting into even more basic issues - like why we're supposed to believe that code like:
select
...
from {{ source('jaffle_shop', 'orders') }}
left join {{ source('jaffle_shop', 'customers') }} using (customer_id)
Is more readable or maintainable than what it compiles into:
select
...
from raw.jaffle_shop.orders
left join raw.jaffle_shop.customers using (customer_id)
I'm happy it works for you. But I'm just not seeing the magic here.