---
title: "Create a materialized view"
method: POST
path: "/v1/materialized_view/{id}/create"
tags: ["MaterializedView", "Data"]
---

# Create a materialized view

`POST /v1/materialized_view/{id}/create`

Create a materialized view at identifier `id`. The view may be
query-backed, UDTF-backed, or chunker-backed, controlled by the
`kind` discriminator.

## Request body

- CreateMaterializedViewRequest
  - `identity` Identity — Identity information of a request.
    - `api_key` string — API key for authentication. REST NAMESPACE ONLY This is passed via the `x-api-key` header.
    - `auth_token` string — Bearer token for authentication. REST NAMESPACE ONLY This is passed via the `Authorization` header with the Bearer scheme (e.g., `Bearer <token>`).
  - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
  - `id` string[] — View identifier path (namespace + view name)
  - `kind` 'query' | 'udtf' | 'chunker', required — The materialized view kind. - `query` — plain query-backed view (no UDTF), 1:1 rows. - `udtf` — batch UDTF-backed view (N:M rows, full refresh). - `chunker`, aka 'scalar_udtf' — chunker view (1:N row expansion, incremental refresh).
  - `source_query` string, required — Opaque serialized representation of the source query that defines the view's input. The format is defined by the client; the namespace server stores it without interpreting it.
  - `output_schema` string, required — Base64-encoded Arrow schema of the view output
  - `udtf_spec` MaterializedViewUdtfEntry
    - `kind` 'udtf' | 'chunker', required — Discriminates a batch UDTF (`udtf`, full-overwrite refresh) from a chunker (`chunker`, incremental 1:N refresh). Must match the enclosing request's `kind`.
    - `udtf` string, required — Base64-encoded UDTFSpec / ChunkerSpec JSON envelope (per kind).
    - `udtf_sha` string, required — SHA-256 checksum of the envelope; server validates.
    - `udtf_name` string, required — Name of the UDTF
    - `udtf_version` string, required — Version of the UDTF
    - `input_columns` string[], nullable — Source Lance field paths the UDTF reads. Nested fields use dot-separated segments; use backtick-quoted segments for literal dots and double backticks inside quoted segments. Null means all fields (batch UDTF only).
    - `partition_by` string, nullable — Batch UDTF only. Lance field path used as the field-value partition key for partition-parallel execution. Nested fields use dot-separated segments; use backtick-quoted segments for literal dots and double backticks inside quoted segments. Mutually exclusive with `partition_by_indexed_column`.
    - `partition_by_indexed_column` string, nullable — Batch UDTF only. Lance field path with an IVF-family index used for index-based partitioning. Nested fields use dot-separated segments; use backtick-quoted segments for literal dots and double backticks inside quoted segments. The server validates the index exists at create time.
    - `num_cpus` number, nullable — Ray actor CPU request.
    - `num_gpus` number, nullable — Ray actor GPU request.
    - `memory` integer, nullable — Ray actor memory request, in bytes.
    - `error_handling` object, nullable — Batch UDTF only. Serialized ErrorHandlingConfig controlling partition-grain fail/retry/skip behavior.
    - `batch` boolean, nullable — Chunker only. True for a batched chunker; affects how the worker dispatches input rows.
    - `manifest` string, nullable — JSON-serialized GenevaManifest for the UDTF environment.
    - `manifest_checksum` string, nullable — SHA-256 checksum of the manifest content.
  - `with_no_data` boolean — If false, the server kicks off an initial refresh immediately after creating the view and the response includes a job ID.
  - `auto_refresh` boolean, nullable — If true, the view is automatically refreshed when source-table data changes past the deployment-level threshold. Boolean opt-in only; the threshold and cooldown are configured on the deployment, not per-view.

## Response `201`

Materialized view created

- CreateMaterializedViewResponse
  - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
  - `version` integer, required — The commit version that created the materialized view
  - `job_id` string, nullable — Refresh job ID, populated only when `with_no_data` was false.

## Other responses

- `400` — Indicates a bad request error. It could be caused by an unexpected request body format or other forms of request validation failure, such as invalid json. Usually serves application/json content, although in some cases simple text/plain content might be returned by the server's middleware.
- `401` — Unauthorized. The request lacks valid authentication credentials for the operation.
- `403` — Forbidden. Authenticated user does not have the necessary permissions.
- `404` — A server-side problem that means can not find the specified resource.
- `409` — The request conflicts with the current state of the target resource.
- `503` — The service is not ready to handle the request. The client should wait and retry. The service may additionally send a Retry-After header to indicate when to retry.
- `5XX` — A server-side problem that might not be addressable from the client side. Used for server 5xx errors without more specific documentation in individual routes.

---

[API](https://skmtc.net/lancedb/apis/lance-namespace-specification.md) · [All operations](https://skmtc.net/lancedb/apis/lance-namespace-specification/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/lancedb/lance-namespace-specification/revisions/d5b7c114f475/schema)