Skip to main content
This page shows you how to create a collection with various configurations.

Parameters

Create a collection from scratch

The simplest way to create a collection is to provide the collection name and the field index configurations. These examples explicitly select Japanese, Korean, and English analyzers for content. Select the analyzers that fit your data using Choose text analyzers; omitting analyzers uses ["standard"].
A successful REST request returns 201 Created. Collection creation also creates the default branch, main:
Collection and ref timestamps, including source.asOf, use numeric Unix epoch milliseconds. The create response is intentionally compact. Use describe or list to retrieve indexConfigs, document counts, and the full collection model. 201 confirms catalog creation; it does not guarantee query-serving readiness or completed indexing. Handle loading and retry states using actual operations; there is no collection-status readiness field to poll.

Create a collection with native embeddings

Native embeddings let LambdaDB derive vector values from a source text field. Define the vector field with an embedding block. The source field must be a text field in the same collection. For supported models and configuration rules, see Native embeddings.
For native embedding vector fields, do not send top-level dimensions or similarity in the field config. LambdaDB resolves and stores those values under embedding.

Create a partitioned collection

LambdaDB supports hash-based partitioning for a specified field. You choose the partition field and count through partitionConfig. At query time, supply partitionFilter with values of that field to search only the corresponding physical partitions; other partitions are not searched. Omitting partitionFilter leaves all partitions in the search scope. This is separate from LambdaDB’s internal sharding, which distributes execution and exposes no shard-count or placement setting to users.
Currently, only keyword type is supported for partitioning.

Snapshot retention

Every collection retains committed snapshots for 30 days by default. Set snapshotRetentionInDays to an integer from 1 through 31 when creating the collection, or change it later with the collection update API. Snapshots pinned by an existing tag remain available even after this retention period expires. Use tags to preserve specific committed versions as long-term savepoints. A tag protects its pinned snapshot, not the collection’s entire history. Collection metadata tags are labels and do not pin snapshots. Omitting retention on create selects the default; explicitly sending null is rejected. See Collection PATCH rules for update and metadata-tag semantics. Point-in-time history is available by creating a branch rather than cloning another collection. A source.asOf value is a Unix epoch timestamp in milliseconds and must refer to a branch in the same collection. See Branches, tags, and aliases.

Collection limits