--- title: "Create collection" method: PUT path: "/collections/{collection_name}" tags: ["Collections"] --- # Create collection `PUT /collections/{collection_name}` Create new collection with given parameters ## Path parameters - `collection_name` string, required ## Query parameters - `timeout` integer ## Request body - CreateCollection — Operation for creating new collection and (optionally) specify index params - `vectors` union — Vector params separator for single and multiple vector modes Single mode: { "size": 128, "distance": "Cosine" } or multiple mode: { "default": { "size": 128, "distance": "Cosine" } } - VectorParams — Params of single vector data storage - `size` integer, required — Size of a vectors used - `distance` 'Cosine' | 'Euclid' | 'Dot' | 'Manhattan', required — Type of internal tags, build from payload Distance function types used to compare vectors - `hnsw_config` union — Custom params for HNSW index. If none - values from collection configuration are used. - HnswConfigDiff - `m` integer, nullable — Number of edges per node in the index graph. Larger the value - more accurate the search, more space required. - `ef_construct` integer, nullable — Number of neighbours to consider during the index building. Larger the value - more accurate the search, more time required to build the index. - `full_scan_threshold` integer, nullable — Minimal size threshold (in KiloBytes) below which full-scan is preferred over HNSW search. This measures the total size of vectors being queried against. When the maximum estimated amount of points that a condition satisfies is smaller than `full_scan_threshold_kb`, the query planner will use full-scan search instead of HNSW index traversal for better performance. Note: 1Kb = 1 vector of size 256 - `max_indexing_threads` integer, nullable — Number of parallel threads used for background index building. If 0 - automatically select from 8 to 16. Best to keep between 8 and 16 to prevent likelihood of building broken/inefficient HNSW graphs. On small CPUs, less threads are used. - `on_disk` boolean, nullable — Deprecated: use `memory` instead. Store HNSW index on disk. If set to false, the index will be stored in RAM. Default: false - `memory` union — Memory placement of the HNSW graph. Overrides the deprecated `on_disk` flag if both are set. Default: `cached` (`cold` if `on_disk` is set to true). - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - `payload_m` integer, nullable — Custom M param for additional payload-aware HNSW links. If not set, default M will be used. - `inline_storage` boolean, nullable — Store copies of original and quantized vectors within the HNSW index file. Default: false. Enabling this option will trade the search speed for disk usage by reducing amount of random seeks during the search. Requires quantized vectors to be enabled. Multi-vectors are not supported. - unknown - `quantization_config` union — Custom params for quantization. If none - values from collection configuration are used. - union - ScalarQuantization - `scalar` ScalarQuantizationConfig, required - … - ProductQuantization - `product` ProductQuantizationConfig, required - … - BinaryQuantization - `binary` BinaryQuantizationConfig, required - … - TurboQuantization - `turbo` TurboQuantQuantizationConfig, required - … - unknown - `on_disk` boolean, nullable — Deprecated: use `memory` instead. If true, vectors are served from disk, improving RAM usage at the cost of latency Default: false - `memory` union — Memory placement of the original vector storage. Overrides the deprecated `on_disk` flag if both are set. `pinned` is not supported for dense vector storage. Default: `cached` (`cold` if `on_disk` is set to true). - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - `datatype` union — Defines which datatype should be used to represent vectors in the storage. Choosing different datatypes allows to optimize memory usage and performance vs accuracy. - For `float32` datatype - vectors are stored as single-precision floating point numbers, 4 bytes. - For `float16` datatype - vectors are stored as half-precision floating point numbers, 2 bytes. - For `uint8` datatype - vectors are stored as unsigned 8-bit integers, 1 byte. It expects vector elements to be in range `[0, 255]`. - For `turbo4` datatype - vectors are quantized to 4 bits per element using the TurboQuant algorithm. - 'float32' | 'uint8' | 'float16' | 'turbo4' - unknown - `multivector_config` union - MultiVectorConfig - `comparator` 'max_sim', required - unknown - object - `shard_number` integer, nullable — For auto sharding: Number of shards in collection. - Default is 1 for standalone, otherwise equal to the number of nodes - Minimum is 1 For custom sharding: Number of shards in collection per shard group. - Default is 1, meaning that each shard key will be mapped to a single shard - Minimum is 1 - `sharding_method` union — Sharding method Default is Auto - points are distributed across all available shards Custom - points are distributed across shards according to shard key - 'auto' | 'custom' - unknown - `replication_factor` integer, nullable — Number of shards replicas. Default is 1 Minimum is 1 - `write_consistency_factor` integer, nullable — Defines how many replicas should apply the operation for us to consider it successful. Increasing this number will make the collection more resilient to inconsistencies, but will also make it fail if not enough replicas are available. Does not have any performance impact. - `on_disk_payload` boolean, nullable — Deprecated: use `payload.memory` instead. If true - point's payload will not be stored in memory. It will be read from the disk every time it is requested. This setting saves RAM by (slightly) increasing the response time. Note: those payload values that are involved in filtering and are indexed - remain in RAM. Default: true - `payload` union — Configuration of the payload storage - PayloadStorageParams — Params of the payload storage - `memory` union — Memory placement of the payload storage. Overrides the deprecated `on_disk_payload` flag if both are set. `pinned` is not supported for payload storage. Default: `cold` (`cached` if `on_disk_payload` is set to false). - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - unknown - `hnsw_config` union — Custom params for HNSW index. If none - values from service configuration file are used. - HnswConfigDiff - `m` integer, nullable — Number of edges per node in the index graph. Larger the value - more accurate the search, more space required. - `ef_construct` integer, nullable — Number of neighbours to consider during the index building. Larger the value - more accurate the search, more time required to build the index. - `full_scan_threshold` integer, nullable — Minimal size threshold (in KiloBytes) below which full-scan is preferred over HNSW search. This measures the total size of vectors being queried against. When the maximum estimated amount of points that a condition satisfies is smaller than `full_scan_threshold_kb`, the query planner will use full-scan search instead of HNSW index traversal for better performance. Note: 1Kb = 1 vector of size 256 - `max_indexing_threads` integer, nullable — Number of parallel threads used for background index building. If 0 - automatically select from 8 to 16. Best to keep between 8 and 16 to prevent likelihood of building broken/inefficient HNSW graphs. On small CPUs, less threads are used. - `on_disk` boolean, nullable — Deprecated: use `memory` instead. Store HNSW index on disk. If set to false, the index will be stored in RAM. Default: false - `memory` union — Memory placement of the HNSW graph. Overrides the deprecated `on_disk` flag if both are set. Default: `cached` (`cold` if `on_disk` is set to true). - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - `payload_m` integer, nullable — Custom M param for additional payload-aware HNSW links. If not set, default M will be used. - `inline_storage` boolean, nullable — Store copies of original and quantized vectors within the HNSW index file. Default: false. Enabling this option will trade the search speed for disk usage by reducing amount of random seeks during the search. Requires quantized vectors to be enabled. Multi-vectors are not supported. - unknown - `wal_config` union — Custom params for WAL. If none - values from service configuration file are used. - WalConfigDiff - `wal_capacity_mb` integer, nullable — Size of a single WAL segment in MB - `wal_segments_ahead` integer, nullable — Number of WAL segments to create ahead of actually used ones - `wal_retain_closed` integer, nullable — Number of closed WAL segments to retain - unknown - `optimizers_config` union — Custom params for Optimizers. If none - values from service configuration file are used. - OptimizersConfigDiff - `deleted_threshold` number, double, nullable — The minimal fraction of deleted vectors in a segment, required to perform segment optimization - `vacuum_min_vector_number` integer, nullable — The minimal number of vectors in a segment, required to perform segment optimization - `default_segment_number` integer, nullable — Target amount of segments optimizer will try to keep. Real amount of segments may vary depending on multiple parameters: - Amount of stored points - Current write RPS It is recommended to select default number of segments as a factor of the number of search threads, so that each segment would be handled evenly by one of the threads If `default_segment_number = 0`, will be automatically selected by the number of available CPUs - `max_segment_size` integer, nullable — Do not create segments larger this size (in kilobytes). Large segments might require disproportionately long indexation times, therefore it makes sense to limit the size of segments. If indexation speed have more priority for your - make this parameter lower. If search speed is more important - make this parameter higher. Note: 1Kb = 1 vector of size 256 - `memmap_threshold` integer, nullable — Maximum size (in kilobytes) of vectors to store in-memory per segment. Segments larger than this threshold will be stored as read-only memmapped file. Memmap storage is disabled by default, to enable it, set this threshold to a reasonable value. To disable memmap storage, set this to `0`. Note: 1Kb = 1 vector of size 256 Deprecated since Qdrant 1.15.0 - `indexing_threshold` integer, nullable — Maximum size (in kilobytes) of vectors allowed for plain index, exceeding this threshold will enable vector indexing Default value is 20,000, based on . To disable vector indexing, set to `0`. Note: 1kB = 1 vector of size 256. - `flush_interval_sec` integer, nullable — Minimum interval between forced flushes. - `max_optimization_threads` union — Max number of threads (jobs) for running optimizations per shard. Note: each optimization job will also use `max_indexing_threads` threads by itself for index building. If "auto" - have no limit and choose dynamically to saturate CPU. If 0 - no optimization threads, optimizations will be disabled. - union - 'auto' - integer - unknown - `prevent_unoptimized` boolean, nullable — If enabled, the service will try to prevent the creation of large unoptimized segments. When enabled, new points written to segments larger than the indexing threshold are stored as "deferred points": they are persisted in the WAL and segments, but excluded from read/search results until the corresponding segments are optimized (e.g. indexed, quantized, or moved to mmap storage). Update requests with `wait=true` will only return after the deferred points become visible, which may significantly increase the perceived latency between submitting an update and its completion. Update requests with `wait=false` are not affected. Default is disabled. - unknown - `quantization_config` union — Quantization parameters. If none - quantization is disabled. - union - ScalarQuantization - `scalar` ScalarQuantizationConfig, required - `type` 'int8', required - `quantile` number, float, nullable — Quantile for quantization. Expected value range in [0.5, 1.0]. If not set - use the whole range of values - `always_ram` boolean, nullable — Deprecated: use `memory` instead. If true - quantized vectors always will be stored in RAM, ignoring the config of main storage - `memory` union — Memory placement of quantized vectors. Overrides the deprecated `always_ram` flag if both are set. Default: follow the memory placement of the original vector storage. - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - ProductQuantization - `product` ProductQuantizationConfig, required - `compression` 'x4' | 'x8' | 'x16' | 'x32' | 'x64', required - `always_ram` boolean, nullable — Deprecated: use `memory` instead. - `memory` union — Memory placement of quantized vectors. Overrides the deprecated `always_ram` flag if both are set. Default: follow the memory placement of the original vector storage. - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - BinaryQuantization - `binary` BinaryQuantizationConfig, required - `always_ram` boolean, nullable — Deprecated: use `memory` instead. - `memory` union — Memory placement of quantized vectors. Overrides the deprecated `always_ram` flag if both are set. Default: follow the memory placement of the original vector storage. - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - `encoding` union - 'one_bit' | 'two_bits' | 'one_and_half_bits' - unknown - `query_encoding` union — Asymmetric quantization configuration allows a query to have different quantization than stored vectors. It can increase the accuracy of search at the cost of performance. - 'default' | 'binary' | 'scalar4bits' | 'scalar8bits' - unknown - TurboQuantization - `turbo` TurboQuantQuantizationConfig, required - `always_ram` boolean, nullable — Deprecated: use `memory` instead. - `memory` union — Memory placement of quantized vectors. Overrides the deprecated `always_ram` flag if both are set. Default: follow the memory placement of the original vector storage. - 'cold' | 'cached' | 'pinned' — Memory placement of a component's data. Data is always persisted on disk regardless of this setting; it only controls how the data is held in RAM. Options: * `Cold` - Data is not pre-loaded from disk to RAM. Preferred for rarely queried components or components larger than RAM size. First request might be slow, but data is cached with usage. * `Cached` - Data is pre-loaded into disk-cache RAM on start. First request is fast, but data may be evicted if there is not enough memory and some other component's data is used more frequently. * `Pinned` - Data is loaded in RAM and never evicted. First request is fast, but the component must fit in RAM at all times. Recommended for frequently queried small components like quantized vectors or primary indexes. - unknown - `bits` union - 'bits1' | 'bits1_5' | 'bits2' | 'bits4' - unknown - unknown - `sparse_vectors` object, nullable — Sparse vector data config. - `strict_mode_config` union — Strict-mode config. - StrictModeConfig - `enabled` boolean, nullable — Whether strict mode is enabled for a collection or not. - `max_query_limit` integer, nullable — Max allowed `limit` parameter for all APIs that don't have their own max limit. - `max_timeout` integer, nullable — Max allowed `timeout` parameter. - `unindexed_filtering_retrieve` boolean, nullable — Allow usage of unindexed fields in retrieval based (e.g. search) filters. - `unindexed_filtering_update` boolean, nullable — Allow usage of unindexed fields in filtered updates (e.g. delete by payload). - `search_max_hnsw_ef` integer, nullable — Max HNSW ef value allowed in search parameters. - `search_allow_exact` boolean, nullable — Whether exact search is allowed. - `search_max_oversampling` number, double, nullable — Max oversampling value allowed in search. - `upsert_max_batchsize` integer, nullable — Max batchsize when upserting - `search_max_batchsize` integer, nullable — Max batchsize when searching - `max_collection_vector_size_bytes` integer, nullable — Max size of a collections vector storage in bytes, ignoring replicas. - `read_rate_limit` integer, nullable — Max number of read operations per minute per replica - `write_rate_limit` integer, nullable — Max number of write operations per minute per replica - `max_collection_payload_size_bytes` integer, nullable — Max size of a collections payload storage in bytes - `max_points_count` integer, nullable — Max number of points estimated in a collection - `filter_max_conditions` integer, nullable — Max conditions a filter can have. - `condition_max_size` integer, nullable — Max size of a condition, eg. items in `MatchAny`. - `multivector_config` union — Multivector strict mode configuration - StrictModeMultivectorConfig - unknown - `sparse_config` union — Sparse vector strict mode configuration - StrictModeSparseConfig - unknown - `max_payload_index_count` integer, nullable — Max number of payload indexes in a collection - `max_resident_memory_percent` integer, nullable — Deprecated: use the node-wide quota config (`PUT /quotas`) instead, which caps the same resource for every collection. Scheduled for removal in 1.21. Reject memory-consuming update operations (e.g. upsert, set payload) when the process resident memory exceeds this percentage of total system memory (or cgroup limit). Value in [1, 100]. Memory is a node-wide resource, so this only tightens the quota for one collection; it cannot lift it. Delete operations are not affected, so callers can still free memory. - unknown - `metadata` union — Arbitrary JSON metadata for the collection This can be used to store application-specific information such as creation time, migration data, inference model info, etc. - Payload - unknown ## Response `200` successful operation - object - `usage` union - Usage — Usage of the hardware resources, spent to process the request - `hardware` union - HardwareUsage — Usage of the hardware resources, spent to process the request - `cpu` integer, required - `payload_io_read` integer, required - `payload_io_write` integer, required - `payload_index_io_read` integer, required - `payload_index_io_write` integer, required - `vector_io_read` integer, required - `vector_io_write` integer, required - unknown - `inference` union - InferenceUsage - `models` object, required - unknown - unknown - `time` number, float — Time spent to process this request - `status` string - `result` boolean ## Other responses - `default` — error - `4XX` — error --- [API](https://skmtc.net/qdrant/apis/qdrant-api.md) · [All operations](https://skmtc.net/qdrant/apis/qdrant-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/qdrant/qdrant-api/revisions/d08b1f613f29/schema)