docs: qualify what deployments do with materialized views

The SDK now sends CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW
to a db:// deployment as SQL, and refuses source_version on a remote
refresh. Current Sophon source accepts both statements, with CASCADE and
WITH (full = true), but only on deployments that enable materialized
views, and whether a refresh rebuilds the view or reconciles changes
depends on configuration. The pages said there is no CREATE MATERIALIZED
VIEW statement, that refreshes are incremental by default and that
CASCADE is not implemented.

The refresh, management and SQL reference pages now describe what the
SDK sends, say that materialized views are experimental and must be
enabled on a deployment, and leave refresh behaviour, CASCADE and the
job type to the deployment's version and configuration. The SQL and
management summaries list CREATE MATERIALIZED VIEW. No deployment was
exercised.
This commit is contained in:
Brendan Clement
2026-10-06 20:45:28 -07:00
parent 622e6078c1
commit bbadf0dbea
6 changed files with 52 additions and 38 deletions
@@ -73,23 +73,22 @@ argument; every refresh is a full one.
<Badge color="red">Enterprise</Badge>
`create_materialized_view` works on a `db://` connection as well as a local one.
What changes is where the refresh runs -- across the cluster rather than in your
process -- and that SQL can drive it:
`create_materialized_view` and `refresh` also work on a `db://` connection.
There the SDK sends them to the deployment as SQL -- `CREATE MATERIALIZED VIEW`
and `REFRESH MATERIALIZED VIEW` -- and the work runs on the cluster rather than
in your process. `source_version` is for local views only; the SDK refuses it
on a remote refresh.
```sql
REFRESH MATERIALIZED VIEW chunks
```
Materialized views are experimental on a deployment, which has to have them
enabled. How its refresh works -- rebuilding the whole view, as above, or
reconciling what changed in the source -- depends on its LanceDB Enterprise
version and configuration, and so do the options
[`REFRESH MATERIALIZED VIEW`](/sql/dml/refresh#refresh-materialized-view)
accepts.
`WITH (full = true)` recomputes every row instead of reconciling what changed
in the source since the last refresh. `SHOW MATERIALIZED VIEWS` lists them, which is
cheaper than `list_materialized_views` -- that method finds views by reading
every table's schema, so it costs one open per table.
<Note>
`CASCADE` is accepted by the parser but not yet implemented. A view built on
another view is refreshed by refreshing each in dependency order.
</Note>
`SHOW MATERIALIZED VIEWS` lists them, which is cheaper than
`list_materialized_views` -- that method finds views by reading every table's
schema, so it costs one open per table.
## Working with the view {#working-with-the-view}