One dbt Project, Every Client: Building a Config-Driven FinOps Platform on Databricks

### Which of these best describes you?

- [x] dbt Community member
- [ ] Partner
- [ ] dbt Labs employee
- [ ] Other

### What's your idea for new content?

At Nexaminds, we built DataWatch, a Databricks FinOps cost-attribution product we deploy across different client workspaces without touching SQL between engagements. dbt is the reason that's possible, and this post walks through why.
The core problem: Databricks bills by DBU, but native billing tables only show totals — not which team or job actually spent it. Every client also tags (or doesn't tag) their clusters differently. Rather than forking a codebase per client, dbt's layered model structure, reusable macros, var()-driven configuration, and snapshots let us solve the problem once and reuse it everywhere.
Specifically, the post would cover:

- A reusable attribution macro — a 3-tier fallback (cluster tag → job owner → cluster owner → unattributed) that lands every dollar on a team even when tagging discipline is inconsistent, written once as a macro instead of copy-pasted logic
- var() over hardcoding — every client-specific value (tag keys, catalogs, thresholds) lives in one YAML config file, so onboarding a new client means editing config, not SQL
- SCD Type 2 snapshots for the team dimension, so cost history stays accurate when a client reorganizes mid-engagement
- DuckDB/Databricks target parity — developing and testing the full project locally against DuckDB, then pointing the same models at a live Databricks workspace for production, which cuts engagement setup time to almost nothing
- dbt tests as a release gate, not a warning — a singular test on attribution coverage blocks report delivery in CI if unattributed spend crosses a threshold

**Why do you think this content is important?**
Most dbt content addresses a single team modeling their own warehouse. There's much less written about the pattern needed when the same dbt project has to serve many different organizations' data with different tagging conventions, thresholds, and workspace layouts — a common situation for consultancies, platform teams, and anyone building a dbt-based product rather than a single internal pipeline. The pattern (config over code, macros over duplication, tests as hard gates) is broadly reusable outside of FinOps specifically.

**Who will this new content help?**
Analytics engineers and consultants who deliver dbt projects to multiple clients or business units and want to avoid maintaining a forked codebase per deployment. Also relevant to anyone building a dbt-based data product (rather than an internal warehouse) who needs the same models to behave differently per tenant without duplicating logic.

### Where would you recommend this content live on the docs.getdbt.com?

https://docs.getdbt.com/blog

The proposed destination is the docs.getdbt.com blog; start by reviewing existing blog content and its contribution conventions. Draft the post around config-driven multi-client projects, reusable macros, var()-based configuration, snapshots, DuckDB/Databricks parity, and CI test gates, with the listed FinOps use case and audience clearly addressed.

Written by the indexing model from the issue text.