I am trying to settle a design default for our declarative pipelines, and I would like to hear how others decide between streaming tables and materialized views when a table could be built either way.

When I started with streaming tables, I thought they carry an ownership cost. The table belongs to the pipeline that defines it, no other pipeline can write it, and moving it later is work. So then I could  build everything as materialized views

On the reviewing the docs, the ownership model looks to be the same for both. A materialized view is also managed by its pipeline, cannot be refreshed from anywhere else, and cannot be used as a streaming source outside that pipeline. If anything, streaming tables are the more open of the two, since published ones accept some DML from outside (the documented GDPR delete path) while materialized views accept none. 

Here is the mental model I carry so far (please correct me if i am off somewhere)

(1) A streaming table processes each record exactly once from an incrementally growing source, so results are cumulative; if I change the transformation, existing rows keep the old logic until a full refresh. A materialized view is a declared result, recomputed to match its query over the current upstream state, so it absorbs source updates and deletes, and new logic lands on the next refresh without ceremony.

(2) Only a streaming table can be the target of AUTO CDC (SCD type 1 or 2), and only a streaming table accepts multiple feeder flows, for example a once=True backfill running beside the continuous feed. A materialized view is one query, always.

(3) Materialized views refresh incrementally when they can and fall back to full recompute when they cannot, and the boundary is not always obvious. A non-deterministic predicate like current_date() in the WHERE clause was enough to defeat incremental refresh for us.

Nearly everything we run today is streaming tables fed by AUTO CDC, with materialized views only where a moving window is part of the table's definition. My questions are,

1. Do you default to materialized views and reach for streaming tables only when streaming semantics force it, or the reverse?

2. How do you verify a materialized view refresh actually ran incrementally, and do you monitor for the day it silently degrades to full recompute?

3. For keyed upserts, is there a case where you would model the merge as a materialized view over the change feed instead of AUTO CDC into a streaming table?

4. Since both object types are pipeline-owned, what is your pattern for handing a dataset across team boundaries? A second pipeline reading the change feed, a sink, or a plain Delta table maintained by a job?

If you have run both at scale, I would appreciate hearing where your defaults settled.

Thank you!