Consistency levels trade freshness and correctness for latency and availability
Qdrant exposes consistency on both the write and read paths. On writes, write_consistency_factor controls how many replicas of a shard must acknowledge an operation before it is considered successful - one, a majority, or all. On reads, the consistency parameter controls how many replicas must respond before the result is returned - one, quorum, majority, or all. There is also write_ordering, which controls whether the WAL is flushed before or after the write is applied, trading durability for latency. These are not global settings; they can be set per request, so a latency-sensitive endpoint can read with consistency=one while a correctness-sensitive endpoint reads with consistency=all.
The mechanism is the same for both paths. A write goes to the shard's primary, which appends it to the WAL and streams it to replicas. With write_consistency_factor=1, the primary acks as soon as it has the write locally; replicas catch up asynchronously. With majority or all, the primary waits for that many replicas to confirm receipt before acking. A read is routed to one or more replicas depending on the consistency level: consistency=one sends it to any healthy replica, consistency=majority sends it to a majority and reconciles (returning the freshest view), consistency=all queries every replica and requires all to respond. Higher consistency means fresher, more complete results, but it costs latency and reduces availability because more replicas must be up and reachable. Lower consistency means faster responses and higher availability, but the result may be stale relative to the most recent write.
Write: write_consistency_factor = 1 | majority | all. Higher means the write is durable on more replicas before acking.
Read: consistency = one | quorum | majority | all. Higher means more replicas must respond and results are fresher.
write_ordering: controls WAL flush behavior relative to applying the write; affects durability window and latency.
Per-request: consistency can be set on each query, so different endpoints can use different levels.
Interaction with failures: consistency=all makes reads and writes fail if any replica is down; lower levels tolerate replica failures.
The trade-off is the classic CAP trade-off expressed at the replica level: stronger consistency costs latency and availability, weaker consistency risks stale reads. In practice I choose consistency=one for search endpoints where a slightly stale result is acceptable and where tail latency matters, consistency=majority for read-your-write scenarios where a user has just submitted data and expects to see it, and consistency=all only for operations that genuinely require the latest state on every replica - which is rare, because all is fragile: a single lagging replica makes the operation fail. The common mistake is assuming the defaults are strong. Qdrant's defaults are permissive, which is a reasonable choice for search but wrong for read-after-write workflows. If your application upserts a point and immediately searches for it, you need either wait=true on the write or a stronger read consistency, or both. The second common mistake is setting consistency=all with a replication factor greater than one and then being surprised when a single slow replica causes timeouts. The third mistake is conflating read consistency with metadata consistency; the consistency parameter governs point data, while collection config and topology are governed by Raft. Version note: the ReadConsistency types and the write_ordering enum values have changed across releases, and the exact defaults differ. Always set them explicitly on paths where the behavior matters.
Version-dependent: the ReadConsistencyType enum and WriteOrdering enum, and their exact values, have changed across Qdrant releases. In some versions the read consistency is expressed as an integer number of replicas rather than a named level; in others it is a named enum. The write_consistency_factor is a collection-level setting, but it can also be overridden per request in some versions. Verify the API and the defaults on your version, and if you are relying on consistency for correctness, test the specific failure scenarios (replica lag, replica down, primary failover) rather than trusting the documentation alone.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
