Hi @IM_01,

You’re correct on both points. A view is purely logical, and a streaming table still needs an append-only source. What makes this work is that streaming is applied to the underlying Delta tables, not to the view object itself.

When you do STREAM(my_view) or spark.readStream.table("my_view"), Databricks expands the view definition (CREATE VIEW my_view AS SELECT ... FROM base_table ...) and builds a streaming plan directly over the base Delta table(s) that the view references. In other words, it’s equivalent to copying the view’s SELECT into your streaming query. The fact that it’s called a view is just naming. The streaming engine still talks to the underlying Delta tables.

The constraint "source must be append‑only" is checked on the Delta table behind the view, not on the view itself. Structured Streaming only supports streaming from Delta tables if upstream writes are append‑only.  UPDATE/DELETE/MERGE will break the stream unless you use options like skipChangeCommits.

In DLT/SDP, streaming tables can only read from streaming/append‑only sources (Auto Loader, streaming tables, Delta tables used in append‑only mode). If the view’s query wraps an append‑only Delta table with allowed operators (projection, filters, certain joins, etc.), then the resulting streaming plan is still over an append‑only source.

So, you're not really streaming from a view in the physical sense. You’re streaming from the append‑only Delta table(s) behind that view, with the view’s SQL simply applied on top of the streaming plan.

Hope that answers your question.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.