---
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.