Qdrant 1.19 made two storage decisions expressible that Kdrant cannot express, and both of them are
about how much RAM a collection needs, which is the number that decides what a deployment costs.
TurboQuant 4-bit became a primary vector storage datatype: a collection can hold only 4-bit quantized
vectors and keep no originals. VectorDatatype in this client offers what Qdrant offered before that,
so a caller who wants it builds the JSON themselves. And the memory strategy across a collection's
components is now one unified setting, "memory": "cold" | "cached" | "pinned", replacing the several
on_disk flags Kdrant models one by one.
The second half is the awkward one, and it has to be got right rather than added. on_disk is on
VectorParams, on the HNSW config, on the payload index parameters 2.2.0 just added, and on the
collection itself. If Qdrant is replacing that with a tier, then Kdrant has a surface that maps onto a
deprecated spelling in four places, and adding the tier beside it without saying which wins would leave
a caller setting both and getting whichever Qdrant happens to prefer.
So this is a modelling milestone before it is a feature. Decide what a collection built with the old
flags means on a server that reads tiers, decide whether on_disk becomes a deprecated alias, and say
so in STABILITY.md rather than in a changelog line nobody rereads.
Exit criterion: a collection created with 4-bit quantization as its storage datatype and an explicit
memory tier per component round-trips through getCollection with what it was created with, asserted
against a real Qdrant, and the relationship between the tier and the existing on_disk flags is stated
where a caller setting both would look.
Qdrant 1.19 made two storage decisions expressible that Kdrant cannot express, and both of them are
about how much RAM a collection needs, which is the number that decides what a deployment costs.
TurboQuant 4-bit became a primary vector storage datatype: a collection can hold only 4-bit quantized
vectors and keep no originals.
VectorDatatypein this client offers what Qdrant offered before that,so a caller who wants it builds the JSON themselves. And the memory strategy across a collection's
components is now one unified setting,
"memory": "cold" | "cached" | "pinned", replacing the severalon_diskflags Kdrant models one by one.The second half is the awkward one, and it has to be got right rather than added.
on_diskis onVectorParams, on the HNSW config, on the payload index parameters2.2.0just added, and on thecollection itself. If Qdrant is replacing that with a tier, then Kdrant has a surface that maps onto a
deprecated spelling in four places, and adding the tier beside it without saying which wins would leave
a caller setting both and getting whichever Qdrant happens to prefer.
So this is a modelling milestone before it is a feature. Decide what a collection built with the old
flags means on a server that reads tiers, decide whether
on_diskbecomes a deprecated alias, and sayso in
STABILITY.mdrather than in a changelog line nobody rereads.Exit criterion: a collection created with 4-bit quantization as its storage datatype and an explicit
memory tier per component round-trips through
getCollectionwith what it was created with, assertedagainst a real Qdrant, and the relationship between the tier and the existing
on_diskflags is statedwhere a caller setting both would look.