# Best Practices for Managing Staging Models in Large-Scale dbt Projects ??

**URL:** <https://discourse.getdbt.com/t/best-practices-for-managing-staging-models-in-large-scale-dbt-projects/19661>\
**Category:** Help\
**Created:** [June 16, 2025, 9:29am UTC](https://discourse.getdbt.com/t/best-practices-for-managing-staging-models-in-large-scale-dbt-projects/19661 "2025-06-16T09:29:16Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![salass00marcelo](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/salass00marcelo/32/5113_2.png) [@salass00marcelo](https://discourse.getdbt.com/u/salass00marcelo)\
**Post date:** [June 16, 2025, 9:29am UTC](https://discourse.getdbt.com/t/best-practices-for-managing-staging-models-in-large-scale-dbt-projects/19661/1 "2025-06-16T09:29:16Z")

</div>

Hey everyone,

I have been working with dbt for the past year and absolutely love how it streamlines analytics engineering. As our team scales,.. our dbt project is growing rapidly—especially the number of staging models.

Right now.., our staging layer feels a bit chaotic. We follow some naming conventions, but managing dependencies and keeping models organized is becoming a challenge. I am curious how others are structuring their staging models in larger projects.

Some specific questions:

Do you recommend splitting staging models across multiple folders by source or domain: ??

How do you handle shared transformations (e.g., cleaning date fields) across multiple staging models: ??

Any advice on keeping ref() dependencies clean and manageable: ?? I have also searched on the web for the solution related to my query and got this blog [https://www.getdbt.com/blog/staging-models-best-practices-and-limiting-view-runs-](https://www.getdbt.com/blog/staging-models-best-practices-and-limiting-view-runs)[sql-training-in-bangalore](https://www.igmguru.com/microsoft-training/microsoft-sql-training-in-bangalore) but couldn’t get enough help.

Would love to hear what’s worked (or not worked) for others. Open to any tips, tools, or docs that helped you keep things sane as your dbt project grew.

Thanks in advance !!

With Regards,  
Marcelo

---

<div class="post-metadata">

**Author:** ![marcelo](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/marcelo/32/6126_2.png) [@marcelo](https://discourse.getdbt.com/u/marcelo)\
**Post date:** [June 16, 2025, 5:21pm UTC](https://discourse.getdbt.com/t/best-practices-for-managing-staging-models-in-large-scale-dbt-projects/19661/2 "2025-06-16T17:21:09Z")

</div>

Hi Marcelo! (Hola tocayo!)

> Do you recommend splitting staging models across multiple folders by source or domain??

Absolutely! In many projects I have worked on, we always opt for splitting by source.

> How do you handle shared transformations (e.g., cleaning date fields) across multiple staging models??

We handle it model by model. Nothing great to suggest on my side on this point.

> Any advice on keeping ref() dependencies clean and manageable:

I’m not sure I’m getting you here. Sometimes you have complex and/or many business rules, so you will have many references and you can’t avoid that complexity. Just keep one ref for each model and at the beginning, in the “importing” area. Let me know about any specific issues so I can try to help you more.

Regarding articles, these can probably lead you to interesting insights. Don’t take them as THE rules, I found myself and my colleagues having counter examples for many recommendations you will find there. Just pick them when they work for you or use them as inspiration for better customized practices:

> **[Your Essential dbt Project Checklist | dbt Developer Blog](https://docs.getdbt.com/blog/essential-dbt-project-checklist)**
>
> A checklist created to guide our internal work, which you can use to clean up your own dbt project.

> **[How to Build a Mature dbt Project from Scratch | dbt Developer Blog](https://docs.getdbt.com/blog/how-to-build-a-mature-dbt-project-from-scratch)**
>
> A guide to how to start and evolve a dbt project.

> **[Essential data modeling techniques for analytics | dbt Labs](https://www.getdbt.com/blog/modular-data-modeling-techniques)**
>
> Explore key data modeling techniques to structure, optimize, and scale your analytics workflows. Learn best practices with dbt.

---

<div class="post-metadata">

**Author:** ![alyk](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/alyk/32/3347_2.png) [@alyk](https://discourse.getdbt.com/u/alyk)\
**Post date:** [June 18, 2025, 3:45pm UTC](https://discourse.getdbt.com/t/best-practices-for-managing-staging-models-in-large-scale-dbt-projects/19661/3 "2025-06-18T15:45:18Z")

</div>

Hi Marcelo -  
On this\>

> [@salass00marcelo](#):
>
> How do you handle shared transformations (e.g., cleaning date fields) across multiple staging models:

We use [macros](https://docs.getdbt.com/docs/build/jinja-macros#macros) for consistently cleaning/transforming certain types of data.

Our dbt project groups things in folder by project layers (stage, intermediate, marts) and sub folder by functional area. In some cases where we wanted to differentiate within subfolder at runtime we’ve added [tags](https://docs.getdbt.com/reference/resource-configs/tags). Example - 99% of our stage models in functional area X need to run daily, but 3 models require an adhoc datastep to occur 1x a year, so we’ve tagged them to allow them to be excluded or run exclusively via selector.

I’ve found the dbt [roadmap documentation](https://github.com/dbt-labs/dbt-core/tree/main/docs/roadmap) information helpful ([Ex.](https://github.com/dbt-labs/dbt-core/blob/main/docs/roadmap/2025-05-new-engine-same-language.md)) for understanding new/upcoming features.

That custom selector `skip_views_but_test_views` you linked is also a cool idea. thanks for sharing.