StrictModeConfig

Per-collection limits Qdrant enforces on the requests it accepts.

The point of strict mode is that the refusal happens on the server. A limit a client checks is a limit the next client does not check, and a shared cluster has more than one client. These are the knobs an operator sets so a query that would take the node down is refused rather than served.

qdrant.updateCollection("docs") {
    strictMode { enabled = true; maxQueryLimit = 1000; unindexedFilteringRetrieve = false }
}

Two of these describe the cluster's health rather than a policy, and are the reason this type is here rather than only in a future release. maxDiskUsagePercent and maxResidentMemoryPercent make a node refuse writes while still serving reads once it crosses them, which is the degraded state an operator most needs the client to be predictable in: Kdrant raises dev.kdrant.KdrantException.ReadOnly for it, which is retryable, rather than the credential failure a bare 403 would otherwise look like.

Which server versions enforce those two is worth knowing before relying on them. Qdrant 1.18 refuses writes over the ceiling. Qdrant 1.19 deprecated the family in favour of a global quota API and does not, so a collection configured this way on 1.19 accepts the setting and keeps accepting writes. The rate limits below are enforced by both.

Qdrant takes further limits this does not model — the per-vector multivector and sparse sub-configs, and the payload-index count. They are additions to this class rather than a different shape, which is why it is a data class with every field defaulted to the server's own choice.