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 either ceiling. Qdrant 1.19 replaced the family with a cluster-wide quota API: it removed maxDiskUsagePercent outright, so a collection configured with it on 1.19 accepts the setting and keeps accepting writes, and it deprecated maxResidentMemoryPercent, which it still enforces and plans to remove in 1.21. Both are deprecated here, and quotas is what replaces them. The rate limits below are unaffected and are enforced by every version.

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.