Qdrant Rust Client

qdrant-client is the official Rust SDK for Qdrant, the high-performance vector search engine used for similarity search, recommendation systems, and retrieval-augmented generation (RAG). It communicates with a Qdrant server over gRPC via Tonic, exposing typed builders for collections, points, vectors, payloads, and query filters so Rust applications can perform vector search without hand-writing protobuf calls.

The crate wraps Qdrant’s full gRPC API surface — collection management, point upserts, batch queries, payload filtering, and snapshot download — behind ergonomic builder types (builders module) and optional serde support for working with typed payloads. It also includes a generate-snippets feature used to keep the crate’s usage documentation in sync with Qdrant’s official multi-language snippet repository.

What You Get

• Typed async gRPC client for all core Qdrant operations: collection CRUD, point upsert/delete, vector search, and payload filtering
• Builder types (PointStruct, SearchPoints, Filter, etc.) that construct request messages without hand-writing protobuf
• Optional serde integration for converting typed Rust structs to/from Qdrant payload JSON
• Snapshot download support (download_snapshots feature) for backing up or restoring collections
• Auth support for API-key and TLS-secured Qdrant Cloud or self-hosted deployments

Common Use Cases

• Building a retrieval-augmented generation (RAG) pipeline that stores document embeddings and performs similarity search against Qdrant
• Implementing a recommendation engine that queries Qdrant for nearest-neighbor items based on user or item vectors
• Managing Qdrant collections and indexes programmatically as part of an application’s startup or migration logic
• Running filtered vector search combining payload conditions (e.g. category, price range) with semantic similarity

Under The Hood

Architecture - The crate is a thin, typed layer over Qdrant’s gRPC API: qdrant.rs and grpc_conversions/ hold the generated/converted protobuf types, while qdrant_client/ and builders/ provide the public-facing client struct and fluent builder types (SearchPointsBuilder, PointStruct, Filter) that assemble those protobuf messages. channel_pool.rs manages gRPC connection pooling and auth.rs handles API-key/TLS credential attachment, keeping transport concerns separate from the request-building API.

Tech Stack - Built on tonic (gRPC) and prost (protobuf) for the wire protocol, tokio for async execution, and derive_builder to generate the fluent builder pattern used throughout the public API. Optional dependencies (reqwest, serde, uuid) are feature-gated so consumers only pull in what they need — e.g. serde is enabled by default for payload (de)serialization, while download_snapshots pulls in reqwest only when snapshot backup/restore is used.

Code Quality - The tests/ directory includes builder_coverage.rs (ensuring every generated protobuf message has a corresponding builder), protos.rs, and a snippet_tests suite that validates the crate’s documented usage snippets actually compile and run against Qdrant’s shared cross-language snippet repository — an unusually rigorous approach to keeping docs and code in sync. This snippet-testing discipline substitutes for a large hand-written integration suite and catches API drift early.

API Design - The builder pattern (SearchPointsBuilder::new(...).limit(10).filter(...)) keeps the many optional gRPC request fields manageable without requiring users to construct raw protobuf structs, and the generate-snippets feature/snippet tests mean the official docs stay runnable rather than going stale. The trade-off is that the API closely tracks Qdrant’s gRPC schema, so users benefit from familiarity with Qdrant’s own concepts (collections, points, payloads) more than from Rust-idiomatic naming alone.