# Using dynamic schemas for snapshots

**URL:** <https://discourse.getdbt.com/t/using-dynamic-schemas-for-snapshots/1070>\
**Category:** Show and Tell\
**Tags:** snapshots, environments\
**Created:** [April 20, 2020, 9:36pm UTC](https://discourse.getdbt.com/t/using-dynamic-schemas-for-snapshots/1070 "2020-04-20T21:36:04Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![cts\_data](https://avatars.discourse-cdn.com/v4/letter/c/82dd89/32.png) [@cts\_data](https://discourse.getdbt.com/u/cts_data)\
**Post date:** [August 12, 2022, 1:56pm UTC](https://discourse.getdbt.com/t/using-dynamic-schemas-for-snapshots/1070/5 "2022-08-12T13:56:16Z")

</div>

I just wanted to put this note here for anyone that utilizes this technique:

If you are attempting to run SlimCI, as of writing, the generate\_database\_name and generate\_schema\_name **within** the snapshot configuration will mark these files as state: modified.

Environment awareness logic for snapshots (and perhaps other models, though I’ve not tested that) must live within dbt\_project.yml in order to not trigger files as modified when comparing across targets (i.e. target == prod and target == ci)

While I did utilize the snapshots macro listed here to have dev point to prod snapshots, this did not solve the issue I was hoping to solve (slimCI running all snapshots in their own temporary schema, which then runs ever child model if using state:modified+)

The magic sauce is explained here: [Caveats to state comparison | dbt Docs](https://docs.getdbt.com/reference/node-selection/state-comparison-caveats#false-positives)

---

_[View the full topic](https://discourse.getdbt.com/t/using-dynamic-schemas-for-snapshots/1070)._