Qdrant
futomaki.qdrant
A Docker Compose file for Qdrant alone, generated from the catalog and checked by the safety inspector. No account needed.
Vector database written in Rust, pairing dense and sparse vectors with structured payloads so that metadata filters and nearest-neighbour search are resolved together in a single query.
Qdrant stores points made of one or more named vectors plus a JSON payload, and applies filtering inside the search rather than after it, so a filtered query does not have to over-fetch candidates and discard most of them. Collections can carry vectors of differing dimensionality, quantisation trades memory for a controlled loss of recall, and payload indexes accelerate frequently filtered fields. It answers over REST and gRPC, supports snapshots for backup, and shards and replicates collections across nodes. A first deployment creates a collection, upserts points and runs a filtered search.
You know it worked when
- The service answers its readiness endpoint and the dashboard loads.
- A collection is created with the intended vector size and distance metric.
- Upserted points are returned by a nearest-neighbour query.
- A query with a payload filter returns only points matching that filter.
- A snapshot can be created and appears in the snapshot listing.
Known sharp edges
- Vector dimensionality and distance metric are fixed at collection creation and cannot be changed without recreating and reloading the collection.
- The index is memory-resident by default and grows with point count, so large collections need on-disk storage or quantisation configured before loading rather than after.
- The API accepts unauthenticated requests unless an API key is set, and both the REST and gRPC ports need protecting.
- Storage must be a persistent volume or the collection and its index disappear with the container.