Materialization changes when a query pays for computation. A view reads its parents when queried; a table stores a result and needs rebuild work and storage.
Compare the complete workload before choosing. A fast dashboard query can still use the wrong freshness schedule or cost more across its refreshes.
Use compiled SQL and representative inputs to investigate expensive transformations. Filter early only when it preserves meaning, and reduce detail before joins that could multiply measures. In supported deployments, --empty can validate query shape with empty inputs, while --sample uses time-based inputs for faster development feedback. Neither proves correctness across the complete reporting history.
Microbatch incremental processing divides large event streams into event-time ranges; choosing it also requires an intentional replay policy for late corrections. Those deployment features are assessed as scenarios here. The browser executes the model, materialization, and filtering tasks.