--- title: "Update collection parameters" method: PATCH path: "/collections/{collection_name}" tags: ["Collections"] --- # Update collection parameters `PATCH /collections/{collection_name}` Update parameters of the existing collection ## Path parameters - `collection_name` string, required ## Query parameters - `timeout` integer ## Request body - UpdateCollection — Operation for updating parameters of the existing collection - `vectors` union — Map of vector data parameters to update for each named vector. To update parameters in a collection having a single unnamed vector, use an empty string as name. - VectorsConfigDiff — Vector update params for multiple vectors { "vector_name": { "hnsw_config": { "m": 8 } } } - unknown - `optimizers_config` union — Custom params for Optimizers. If none - it is left unchanged. This operation is blocking, it will only proceed once all current optimizations are complete - 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 - `params` union — Collection base params. If none - it is left unchanged. - CollectionParamsDiff - `replication_factor` integer, nullable — Number of replicas for each shard - `write_consistency_factor` integer, nullable — Minimal number successful responses from replicas to consider operation successful - `read_fan_out_factor` integer, nullable — Fan-out every read request to these many additional remote nodes (and return first available response) - `read_fan_out_delay_ms` integer, nullable — Delay in milliseconds before sending read requests to remote nodes - `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. - `payload` union — Update params of the payload storage. If none - it is left unchanged. - 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 - unknown - `hnsw_config` union — HNSW parameters to update for the collection index. If none - it is left unchanged. - 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 — Quantization parameters to update. If none - it is left unchanged. - 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 - 'Disabled' - unknown - `sparse_vectors` union — Map of sparse vector data parameters to update for each sparse vector. - SparseVectorsConfig - unknown - `strict_mode_config` union - 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 — Metadata to update for the collection. If provided, this will merge with existing metadata. Individual keys can be removed by setting their value to `null`. - 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)