Restructure Docs - Stage 4a (#2280)

* create Develop and Deploy tabs; move Operations; re-weight pages * move capacity planning page; create section dropdown content * added aliases to frontmatter * update link references to new canonical links; maintain anchoring * address remaining link issues and errors * fix outlier tutorial reference issue * Treat 'develop' and 'deploy' as a unified search space * fix some frontmatter aliases * add section header redirects * fix 'Operations' redirect to go to 'Deploy' tab * update redirects file for * pattern * add :splat to redirect references * Add wildcard to each entry in _redirects file --------- Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>
2026-10-07 20:08:32 +02:00 · 2026-04-20 18:03:45 +02:00
parent 7b463c5ae5
commit 544708f293
155 changed files with 654 additions and 414 deletions
@@ -0,0 +1,144 @@
+---
+title: Administration
+weight: 10
+aliases:
+  - /documentation/administration
+  - /documentation/ops-configuration/administration
+  - /documentation/operations/administration
+---
+
+# Administration
+
+Qdrant exposes administration tools which enable to modify at runtime the behavior of a qdrant instance without changing its configuration manually.
+
+## Recovery mode
+
+*Available as of v1.2.0*
+
+Recovery mode can help in situations where Qdrant fails to start repeatedly.
+When starting in recovery mode, Qdrant only loads collection metadata to prevent
+going out of memory. This allows you to resolve out of memory situations, for
+example, by deleting a collection. After resolving Qdrant can be restarted
+normally to continue operation.
+
+In recovery mode, collection operations are limited to
+[deleting](/documentation/manage-data/collections/#delete-collection) a
+collection. That is because only collection metadata is loaded during recovery.
+
+To enable recovery mode with the Qdrant Docker image you must set the
+environment variable `QDRANT_ALLOW_RECOVERY_MODE=true`. The container will try
+to start normally first, and restarts in recovery mode if initialisation fails
+due to an out of memory error. This behavior is disabled by default.
+
+If using a Qdrant binary, recovery mode can be enabled by setting a recovery
+message in an environment variable, such as
+`QDRANT__STORAGE__RECOVERY_MODE="My recovery message"`.
+
+
+## Strict mode
+
+*Available as of v1.13.0*
+
+Strict mode is a feature to restrict certain type of operations on a collection in order to protect the Qdrant cluster.
+
+The goal is to prevent inefficient usage patterns that could overload the system.
+
+Strict mode ensures a more predictable and responsive service when you do not have control over the queries that are being executed.
+
+Upon crossing a limit, the server will return a client side error with the information about the limit that was crossed.
+
+The `strict_mode_config` can be enabled when [creating](#create-a-collection) a new collection, see [schema definitions](https://api.qdrant.tech/api-reference/collections/create-collection#request.body.strict_mode_config) for all the available `strict_mode_config` parameters.
+
+As part of the config, the `enabled` field act as a toggle to enable or disable the strict mode dynamically.
+
+It is possible to raise the default limits and/or disable strict mode entirely. Though, in order to ensure a stable cluster we strongly recommend to keep strict mode enabled using its default configuration. For disabling strict mode on an existing collection use:
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/disable/" >}}
+
+### Disable retrieving via non indexed payload
+
+Setting `unindexed_filtering_retrieve` to false prevents retrieving points by filtering on a non indexed payload key which can be very slow.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/unindexed-filtering-retrieve/" >}}
+
+Or turn it off later on an existing collection through the [update collection parameters](/documentation/manage-data/collections/#update-collection-parameters) API.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/unindexed-filtering-retrieve-off/" >}}
+
+### Disable updating via non indexed payload
+
+Setting `unindexed_filtering_update` to false prevents updating points by filtering on a non indexed payload key which can be very slow.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/unindexed-filtering-update/" >}}
+
+### Maximum number of payload index count
+
+Setting `max_payload_index_count` caps the maximum number of payload index that can exist on a collection.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-payload-index-count/" >}}
+
+### Maximum query `limit` parameter
+
+Retrieving large result set is expensive.
+
+Setting `max_query_limit` caps the maximum number of points that can be retrieved in a single query.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-query-limit/" >}}
+
+### Maximum `timeout` parameter
+
+Long running operations are often symptomatic of a deeper issue.
+
+Setting `max_timeout` caps the maximum value in seconds for the `timeout` parameter in all API operations.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-timeout/" >}}
+
+### Maximum size of a filtering condition
+
+Large filtering conditions are expensive to evaluate.
+
+Setting `condition_max_size` caps the maximum number of element a filtering condition can have.
+
+e.g. the number of elements in `MatchAny`
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/condition-max-size/" >}}
+
+### Maximum number of conditions in a filter
+
+A large number of filtering conditions are expensive to evaluate.
+
+Setting `filter_max_conditions` caps the maximum number of conditions filters can have.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/filter-max-conditions/" >}}
+
+### Maximum batch size when inserting vectors
+
+Sending very large batch upserts can create internal congestion.  
+
+Setting `upsert_max_batchsize` caps the maximum size in bytes of a batch during vector upserts.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/upsert-max-batchsize/" >}}
+
+### Maximum collection storage size
+
+It is possible to set the maximum size of a collection in terms of vectors and/or payload storage size.
+
+Setting `max_collection_vector_size_bytes` and/or `max_collection_payload_size_bytes` caps the maximum byte size of a collection.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-collection-storage-size-bytes/" >}}
+
+### Maximum points count
+
+Setting `max_points_count` caps the maximum number of points for a collection.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/max-points-count/" >}}
+
+### Rate limiting
+
+An extremely high rate of incoming requests can have a negative impact on the latency.
+
+Setting `read_rate_limit` and/or `write_rate_limit` to cap the maximum number of operations per minute per replica.
+
+When exceeding the maximum number of operations, the client will receive an HTTP 429 error code with a suggested delay before retrying.
+
+{{< code-snippet path="/documentation/headless/snippets/strict-mode/rate-limiting/" >}}