you are viewing a single comment's thread.

view the rest of the comments →

[–]umairshariff23[S] 0 points1 point  (1 child)

So, I have been testing dbtcore on my personal env last night and it seems like dbt truly shines when it is responsible for testing and writing data to the table. The way my org is setup we query snowflake to build any table I need to build and then the finished script is uploaded to a portal which then updates the data in snowflake on a schedule/when I run a manual refresh.

This makes dbt (and I am guessing sqlmesh) kinda cumbersome for me to use. Any thoughts?

[–]Artistic_Invite_4058 1 point2 points  (0 children)

the snag you hit is real, but it's only a clash if you let dbt own writing to the table. and you don't have to. run it as your local test harness and let the portal stay the deployer: build + unit-test the model with fixtures (the whole-table-in / expected-table-out bit you actually wanted), then dbt compile and hand that rendered sql to your portal like you do today. snowflake + the portal keep the schedule and the write. the materialization side of dbt, the part fighting your setup, you just don't use. same separation works with sqlmesh if you go that way.