Skip to main content
Applies to: Embedded ❌, Enterprise ✅ Refresh a materialized view to bring its stored rows up to date after the source table changes.
In SQL this is REFRESH MATERIALIZED VIEW.

​
Refresh a view

In LanceDB Embedded, every refresh rebuilds the view completely from its source query — there is no incremental refresh there. Calling it again with no source changes still rebuilds and commits a new table version. In LanceDB Enterprise, the server chooses the refresh mode instead; pass full=True to force a full rebuild there too. In LanceDB Embedded, the result reports what the refresh did:
LanceDB Enterprise refreshes run through its SQL job adapter, which doesn’t expose these metrics: mode, rows_written and source_version are all None on an Enterprise result, even though the refresh itself ran. Pass source_version=N to refresh against a particular source version instead of the latest. This is a LanceDB Embedded capability only — LanceDB Enterprise’s SQL refresh does not support pinning a source version:
Use view.table.count_rows() for the view’s row count at any time; on LanceDB Embedded it always matches rows_written from the most recent refresh.

​
Automatic refresh

A materialized view can refresh itself on a schedule instead of waiting for an explicit refresh() call. See Auto Refresh for enabling it at creation, the SQL and SDK forms for changing the setting afterward, and how it differs from a computed column’s per-output granularity.

​
When a refresh fails

A refresh replaces the view’s stored rows in one commit, so a failure leaves the view as it was after its last successful refresh. Fix the cause and refresh again.

​
Related guides

Create a materialized view

Define the query a view stores.

Refresh a computed column

The same idea, for a single derived column.

Auto Refresh

Refresh on a schedule instead of calling this yourself.