A streaming table is a Delta table that ingests from a streaming source incrementally, processing each new file or record once and appending it. A materialized view stores the result of a query and refreshes it, incrementally where possible, so readers get precomputed results. In Databricks SQL both are created with one statement and run on serverless compute; the choice is ingestion versus aggregation.
Last updated September 2026.
Use a streaming table to bring data in: files landing in cloud storage, a message stream, anything append-only that keeps arriving. Use a materialized view to serve a result: a daily summary, a pre-joined dashboard dataset, an expensive aggregate you do not want recomputed on every open. Streaming tables feed materialized views; the two are rarely alternatives to each other.
The canonical form uses Auto Loader through read_files:
CREATE STREAMING TABLE bronze.events AS SELECT * FROM STREAM read_files('s3://bucket/events/', format => 'json');
Each file in the folder is processed once. New files are picked up on the next refresh and appended; old files are never re-read. That is what makes ingestion cheap at scale, and it is also the behaviour to remember when someone replaces a file in place: the corrected file is not reprocessed, because the table has already seen that path. A full refresh or a downstream fix is needed.
Streaming tables are refreshed with REFRESH STREAMING TABLE or on a schedule set at creation, and they run on serverless pipelines under the hood, which is one reason the serverless SQL warehouse is the recommended warehouse type.
CREATE MATERIALIZED VIEW gold.daily_revenue AS SELECT order_date, region, sum(amount) AS revenue FROM silver.orders GROUP BY order_date, region;
The result is stored. A dashboard reading the view never runs the aggregation; it reads the rows. Refreshing recomputes the result, incrementally when the query's shape allows it and in full otherwise, and can be scheduled with SCHEDULE at creation or triggered with REFRESH MATERIALIZED VIEW. Between refreshes the data is as old as the last refresh, which is the trade: speed for freshness.
A materialized view is not a regular view. A regular view stores only the query and recomputes it on every read; a dynamic view does the same with per-user logic inside. If the question is about stored results, it is a materialized view; if it is about per-user filtering, it is a dynamic view.
| Streaming table | Materialized view | |
|---|---|---|
| Job | Ingest new data incrementally | Serve a precomputed query result |
| Source | A stream: read_files, Auto Loader, Kafka | Any query over tables and views |
| On refresh | Appends only the new files or records | Recomputes the result, incrementally where possible |
| Replaced source file | Not reprocessed | Reflected on the next refresh |
| Typical layer | Bronze, sometimes silver | Gold, dashboard datasets |
| Compute | Serverless pipelines, created from Databricks SQL | Serverless pipelines, created from Databricks SQL |
Sourced from the Databricks documentation pages on streaming tables and materialized views in Databricks SQL.
Exam tip: "New files keep landing" or "process each file once" points at a streaming table. "Fast dashboard", "precomputed", "does not recompute on every open" points at a materialized view. "Each user sees only their rows" is neither; that is a dynamic view.
The usual distractor swaps the two: a materialized view offered for file ingestion, or a streaming table offered for a summary. A materialized view cannot consume a stream incrementally, and a streaming table does not hold an aggregate. The other distractor is a plain view "refreshed by a scheduled query", which stores nothing and therefore recomputes everything on every read.
A streaming table ingests data incrementally from a streaming source, appending each new file or record once. A materialized view stores the result of a query and refreshes it, so readers get precomputed results instead of rerunning the query.
When a query is expensive and read often, such as a daily aggregate behind a dashboard. The result is stored and refreshed on a schedule, so each open reads rows rather than recomputing the aggregation.
No. A streaming table processes each source file once, so a file replaced in place with the same name is not read again. Correcting the data needs a full refresh of the table or a fix downstream.
You create them from Databricks SQL, and they run on serverless compute (serverless pipelines) rather than on the warehouse itself, which is one of the reasons Databricks recommends serverless SQL warehouses.
Streaming tables versus materialized views is a trade-off chapter in the Data Analyst Associate course, with the syntax, the refresh behaviour and the questions the exam builds around them.
Open the chapter →