An automated feature request arrived asking for a lighter deployment for edge devices, and answering it
turned up something the README does not say and that anybody evaluating this project for an embedded or
edge case has to work out for themselves.
Kdrant is a client. It talks to a Qdrant over a network. For a device that has to hold the index
itself, with no server to reach, the answer is Qdrant Edge, which runs in-process and offline, and this
project is the wrong tool. That is not a limitation to apologise for: it is the boundary of what a client
is, and stating it costs a paragraph.
The reason it needs saying is that everything else in the README points the other way. linuxArm64 is a
published target, the GraalVM image answers its first search 37 ms after process start in 42 MB, and
kdrant-cli is a 5.7 MB static binary. A reader assembling those three facts concludes this runs on
edge hardware, which is true, and may conclude it runs as the vector database, which is not.
The distinction that is worth drawing is between the gateway and the device. An ARM box that queries a
Qdrant elsewhere is exactly what those three facts are for and Kdrant fits it well. A robot or a kiosk
that must answer with no network is a different architecture and a different Qdrant product.
One paragraph in the Platforms section, naming both, so an evaluation spends a minute rather than an
afternoon.
Exit criterion: the README states that Kdrant is a client rather than an embedded engine, names Qdrant
Edge as the answer for a device that holds its own index, and draws the gateway-versus-device line the
existing ARM and native-image claims otherwise leave a reader to draw.
An automated feature request arrived asking for a lighter deployment for edge devices, and answering it
turned up something the README does not say and that anybody evaluating this project for an embedded or
edge case has to work out for themselves.
Kdrant is a client. It talks to a Qdrant over a network. For a device that has to hold the index
itself, with no server to reach, the answer is Qdrant Edge, which runs in-process and offline, and this
project is the wrong tool. That is not a limitation to apologise for: it is the boundary of what a client
is, and stating it costs a paragraph.
The reason it needs saying is that everything else in the README points the other way.
linuxArm64is apublished target, the GraalVM image answers its first search 37 ms after process start in 42 MB, and
kdrant-cliis a 5.7 MB static binary. A reader assembling those three facts concludes this runs onedge hardware, which is true, and may conclude it runs as the vector database, which is not.
The distinction that is worth drawing is between the gateway and the device. An ARM box that queries a
Qdrant elsewhere is exactly what those three facts are for and Kdrant fits it well. A robot or a kiosk
that must answer with no network is a different architecture and a different Qdrant product.
One paragraph in the Platforms section, naming both, so an evaluation spends a minute rather than an
afternoon.
Exit criterion: the README states that Kdrant is a client rather than an embedded engine, names Qdrant
Edge as the answer for a device that holds its own index, and draws the gateway-versus-device line the
existing ARM and native-image claims otherwise leave a reader to draw.