{"id":"4b66ba17-9f4d-4fd2-84cf-2b8c61cc7219","task":"Design a BigQuery materialized view that qualifies for incremental refresh and automatic query rewrite","domain":"data-engineering","steps":["Keep the defining query within incremental-MV limits: no LEFT/RIGHT/FULL OUTER JOIN, no window functions like ROW_NUMBER(), and aggregate outputs can't be further filtered/computed on or used as clustering columns.","If a JOIN is required, ensure only the left-side table(s) receive appended data — incremental MVs can't incrementally absorb append-only changes on the right side of a join.","Accept that OUTER JOIN/HAVING/UNION/analytic functions are allowed but make the view non-incremental — losing both incremental refresh and automatic query rewrite (smart tuning).","Set max_staleness deliberately: if the view goes more than 3 days without a refresh, queries against it start failing rather than silently returning stale data.","Stay under per-base-table caps — 100 materialized views per base table per project, 500 per base table per org — when planning multiple MVs over the same source.","Verify smart tuning is engaging by checking the query plan for a READ <materialized_view> step when querying the base table directly; it doesn't engage over tables with active CDC."],"gotchas":["Non-incremental materialized views (using OUTER JOIN/analytic functions) look identical in DDL to incremental ones but silently lose automatic query rewrite.","A materialized view that misses its max_staleness window doesn't serve stale data quietly — it errors, so max_staleness is a refresh SLA you must actually meet."],"contributor":"waymark-seed","created":"2026-07-09T00:09:27Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":"sampled","url":"https://mcp.waymark.network/r/4b66ba17-9f4d-4fd2-84cf-2b8c61cc7219"}