Only materialize the topmost serving view, not the whole stack

TL;DR: Materialize only the topmost view that serves results, and keep the intermediate views plain. Do not materialize every view in a stacked definition. If your cluster does both transform and serving, use an indexed view instead of a materialized view; a materialized view in that setup just burns memory for no isolation.

Fix

1. Materialize only the topmost view that serves results, and keep the intermediate views plain. Expected: this specific failure stops.

2. If your cluster does both transform and serving, use an indexed view instead of a materialized view; a materialized view in that setup just burns memory for no isolation. Expected: this specific failure stops.

3. Context: Materialize docs Views concept (materializeinc/agent-skills .agents/skills/materialize-docs/concepts/views/index.md): Use a materialized view only for the topmost view whose results will be served; stacked views underneath that exist only to reduce SQL complexity should stay plain views. Expected: this specific failure stops.

Details

Do not materialize every view in a stacked definition. The exception is when the view feeds a sink or SUBSCRIBE, where a materialized view is the right shape. On a shared cluster used for both transform and serving, indexed views beat materialized views; materialized views belong on the compute cluster feeding a sink or SUBSCRIBE, or in a 3-tier setup with the index in the serving cluster.

When to use

You hit exactly this: Only materialize the topmost serving view, not the whole stack.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

the tool named in the title.

Materialize docs Views concept (materializeinc/agent-skills .agents/skills/materialize-docs/concepts/views/index.md): Use a materialized view only for the topmost view whose results will be served; stacked views underneath that exist only to reduce SQL complexity should stay plain views. On a shared cluster used for both transform and serving, indexed views beat materialized views; materialized views belong on the compute cluster feeding a sink or SUBSCRIBE, or in a 3-tier setup with the index in the serving cluster. Resolved: Do not materialize every view in a stacked definition. Materialize only the topmost view that serves results, and keep the intermediate views plain. If your cluster does both transform and serving, use an indexed view instead of a materialized view; a materialized view in that setup just burns memory for no isolation. The exception is when the view feeds a sink or SUBSCRIBE, where a materialized view is the right shape. Source: https://github.com/materializeinc/agent-skills/blob/HEAD/.agents/skills/materialize-docs/concepts/views/index.md