Materialize a Model

A model is a definition, not a dataset: its query is re-run inside every query that reads it. For a model that is a plain SELECT over a clean table, that is exactly right. For a model whose query has three joins and a window function, it means that cleaning runs again inside every audience estimate, every sync, every orchestration tile and every profile lookup — forever.

Materialize turns such a model into a prepared table in one step, and repoints the model at it.

When it is offered

A banner appears on a model Zeotap’s own classifier calls complex — the same classification that decides whether reverse ETL can read a change feed or has to compare whole result sets — when Data Prep is enabled for the workspace.

The model page shows that classification, so what the banner offers and what Zeotap would accept cannot disagree.

What happens

1. You name the new prepared table and choose its rebuild schedule, and whether it should rebuild when its inputs change.
2. Zeotap creates a prepared table whose recipe is the model’s own SQL, as a single step.
3. It builds it.
4. Only after that first build succeeds — and only if the built table’s columns match the model’s, by name, ignoring case and order — the model is repointed: its query becomes SELECT * FROM cdp_prep.<table>.

Until step 4, the model goes on running its own query, so nothing downstream ever sees a half-finished state. Audiences, computed attributes, syncs and orchestrations reference the model, not its SQL, so none of them needs changing.

What it costs, and what it saves

You are trading one repeated cost for one scheduled cost. Whether that is a good trade depends on how often the model is read and how expensive its query is — a heavy query read many times a day is the clear case; a cheap query read twice a week is not.

The prepared table is also a table your warehouse now stores, and it is only as fresh as its last build. Choose a schedule, or a trigger, that matches how fresh the model’s readers need it to be. See Triggers & Freshness.

Reversing it

Dematerialize restores the model’s original query and detaches the prepared table.

The prepared table is left standing, with its data. Deleting it is a separate, explicit act, and the confirmation says so and links to it.

Dematerialize needs only permission to edit models — deliberately, so a workspace whose Data Prep entitlement has been revoked can still move its models off a table that is no longer refreshing.

After materializing

The prepared table is an ordinary prepared table. You can open it, replace the single SQL step with typed steps, make it incremental, add data tests, and give it a trigger — all without touching the model again.

One of those is worth doing deliberately if syncs read the model. A materialized model is compared whole-result-set by its syncs, exactly as the complex model it replaced was. Making the prepared table incremental + merge and turning on Preserve change feed lets those syncs read your warehouse’s change feed again — which is usually the larger saving of the two.

Waking what reads it

Once a model reads a prepared table, the things downstream of it can follow the build rather than their own clocks:

• Reverse ETL and audience syncs gain a switch beside their schedule — “Also run when the prepared table rebuilds”.
• Orchestrations that react to changes in that model wake when the build finishes, rather than waiting for their next reconciliation.

A build that changed nothing wakes nothing, and a sync that already has a run in flight is skipped rather than queued twice.

Next steps

• Incremental Builds
• Triggers & Freshness
• Models