the value and necessity of dev schemas

[ericalouie]

Context

I was at a dbt Meetup last week and someone who uses dbt Cloud + Core at a 200+ person company said that they only have one dev schema (on Snowflake, no less) and they're running into issues where multiple folks are running the same models and messing up other teammates' work. I was shocked!

Proposal

We should do a devhub blog on the value of dev schemas, how we use them, and why it's a high-value feature of dbt Cloud. I think we often take this for granted when this has been our playbook since Day 0.

Points to make

• Main Takeaway: Everyone should have their own dev schema + this is why
• Setting up your warehouse where only BI tools touch the prod schema
• ^They can also move all dev schemas in a separate database if they so choose

Questions for the Audience

• Do you use dev schemas?
• If not, why?
• If so, how has that changed your workflow? How do you currently set this up?

[leoebfolsom]

Good idea. How chaotic that sounds!

[korompaiistvan]

at a previous project, where we migrated a big yarn-ball of SQL sprocs to dbt, we stuck with using a single dev schema. we were a team of about 4 people)
there were a couple reasons:

• it never really occured to us to give everyone their own env so we didn't give it much thought either
• we did not run into problems with this because the beginning of our DAG was fairly stable by the time we moved to dbt, it received very few changes
• our intermediate, marts and activation layers were highly fragmented with essentially single ownership by a developer so it was rare that we would step on each others' toes there
• additionally, we materialized almost all our models as tables, as for historical reasons we were using postgres and we wanted to keep iteration time down as much as possible. views or ephemeral models would have increased compute time quite a bit for small changes at the leafs. using tables would have meant that we would have needed to duplicate a lot of data have we had our own dev schemas