--- title: "Materialized View" sidebarTitle: "Materialized View" description: "SHOW MATERIALIZED VIEWS — creation and refresh are SDK and REFRESH statements, not CREATE." icon: table keywords: ["materialized view", "show materialized views", "sql"] --- Enterprise [SQL runs on a deployment.](/sql) A materialized view stores a query's result as rows, kept current by a refresh -- the counterpart to a [view](/sql/ddl/view), which stores only the query. There is no `CREATE MATERIALIZED VIEW` statement. Creation is [`create_materialized_view`](/management/materialized-view#create) in the SDK, since it needs SDK-level source-table validation (stable row ids) that a bare SQL statement has nowhere to check. Once created, it is entirely a SQL object: queried like a table, refreshed with SQL, listed with SQL. ## SHOW MATERIALIZED VIEWS {#show} ```sql SHOW MATERIALIZED VIEWS ``` Cheaper than the SDK equivalent. `list_materialized_views` finds views by reading every table's schema, costing one open per table; this asks the server. ## Refreshing one {#refresh} ```sql REFRESH MATERIALIZED VIEW chunks ``` See [REFRESH](/sql/dml/refresh#refresh-materialized-view) for the full syntax, including `full = true` and what `CASCADE` does not yet do. ## Dropping one {#drop} A materialized view **is** a table, so it is dropped with [`DROP TABLE`](/sql/ddl/table#drop) -- which is also why dropping one removes stored rows, unlike dropping a [view](/sql/ddl/view#drop). **Enterprise job type:** `mat_view_refresh` for the refresh; `drop_table` for dropping it, same as any table. ## What to read next {#next} Creating one from the SDK, and the stable-row-ids requirement. Incremental refreshes, and what they cost.