# Turning Omni saved query views into dbt models

**URL:** <https://community.omni.co/t/turning-omni-saved-query-views-into-dbt-models/400>\
**Category:** Modeling\
**Tags:** dbt\
**Created:** [October 7, 2025, 11:32pm UTC](https://community.omni.co/t/turning-omni-saved-query-views-into-dbt-models/400 "2025-10-07T23:32:57Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![conner](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.omni.co/conner/32/11_2.png) [@conner](https://community.omni.co/u/conner)\
**Post date:** [October 7, 2025, 11:32pm UTC](https://community.omni.co/t/turning-omni-saved-query-views-into-dbt-models/400/1 "2025-10-07T23:32:57Z")

</div>

As teams explore in Omni, useful transformations will naturally emerge. Instead of leaving them as one-off queries, you can [save the query](https://docs.omni.co/docs/querying-and-sql/saved-views) as an Omni view — a lightweight, virtual transformation (like a CTE you can reference in Omni) that’s easy to reuse and simple for end users.

When a saved view needs better performance (or otherwise warrants materialization in the database), you can create a dbt model for it. Then, the content validator can cleanly remap references from the original Omni view to the new dbt model without breakage. In effect, Omni acts as a “prototyping” layer to let you test what transformations are actually useful to your team before creating a full dbt model. (If you just need to [edit an existing dbt model](https://omni.co/blog/creating-and-editing-dbt-models-with-omnis-dbt-ide), you can do that in Omni, too!)

For example, here’s how a new Customer Fact table might follow this process:

- [**Save query**](https://docs.omni.co/docs/querying-and-sql/saved-views) as an Omni view. An analyst creates a customer fact table by joining Orders and Customers. This gets used widely, so she turns it into an Omni view to make it easier to work with.

- **See how it gets used**. As the table becomes foundational to some dashboards, materializing it in the database would significantly improve performance.

- **Build in dbt**. The analyst recreates the table in a new dbt model, fct\_customers (alternatively, if you had an existing model you wanted to update, you can do so from Omni as well).

- **Swap safely with the content validator.** Use Omni’s content validator to bulk-remap references from the Omni view to the new dbt model, with schema compatibility checks and a preview of impacted content (this is where the co-development pattern comes in handy).

- **Retire the original Omni view.** Deprecate or drop the original “Customer Fact” Omni view once everything points to the dbt model to avoid misalignment.

Here’s a quick tutorial from Sara, one of Omni’s solutions engineers, on how this process works:

[![](https://canada1.discourse-cdn.com/flex004/uploads/omni/original/1X/6dfefb8aa84a4b93806c0e76771b90d6f7a19d04.jpeg "Omni's dbt integration: Prototyping dbt models with Omni") ](https://www.youtube.com/watch?v=Xz1gTT_0EjA)