qdrant: a server, an in-process Edge shard, and a quick start with no authentication

The documented one-line start is explicitly labelled an insecure deployment

The fastest way in is a single command, and the page immediately undercuts it:

docker run -p 6333:6333 qdrant/qdrant

The note under that command says this starts an insecure deployment without authentication, open to all network interfaces, and points to the security documentation for securing an instance. Take both halves seriously, because they are separate problems. Without authentication, the REST and gRPC interfaces accept reads and writes from anyone who can reach them, and a point is not just a vector, it is a vector plus a payload, so whatever you attached to your embeddings is exposed with it. And the port mapping publishes 6333 on every interface of the host rather than on loopback, so a development command run on a laptop on office wifi or a shared VPS is reachable from the network. The page's own instruction is to read the installation and security guides before deploying to production. Connecting a client is the easy part, two lines of Python, and it is not the part that needs the review.

GPU support is a build argument, so the hardware decision happens before you deploy

The Dockerfile opens with an ARG named GPU and a comment saying it can be set to nvidia or amd to enable GPU support, and that it is defined there because it is used in FROM instructions. The Cargo manifest carries the matching compile-time switch, a feature named gpu that turns on gpu/gpu and segment/gpu. Put those together and the picture is clear. You enable it by building the image with a different argument, which means the decision about your hardware is made on a build machine, ahead of time, and the resulting artefact is a different binary. Since the manifest's default feature set is empty, a stock build has no GPU code compiled into it at all, so a container that looks identical from the outside may simply lack the acceleration. If you are evaluating this for a machine with accelerators, find out at build time, not during an incident.

The default feature set is empty, and observability is one of the opt-ins

In the manifest, default = []. Everything interesting about how the server reports and tests itself is a feature you have to ask for. The tracing feature is declared but off unless requested, and the console and console-subscriber features chain into it, as do tracy and tracing-tracy, while tokio-tracing only turns on tokio/tracing. So a default build emits no tracing output, and if you are diagnosing a slow query or a shard problem, the first step is a rebuild with a different feature set rather than a configuration change. Two more features belong to the people writing the server rather than the people running it: chaos-testing, which is declared as an empty feature list, and data-consistency-check, which switches on the collection level check of the same name. staging switches on staging code in the collection, storage and shard crates, and deb is an empty feature. The practical consequence is that a binary, a test result and a benchmark each belong to a specific feature set, and nothing in a running server tells you which one you have.

The build image floats on a latest tag while the manifest names rust-version 1.97

Two toolchain statements sit in the repository and they are not the same kind of statement. Cargo.toml sets edition to 2024 and rust-version to 1.98, which is a floor that Cargo enforces when it builds your own code. The Dockerfile pins its builder to a cargo-chef image whose tag ends in latest-rust-1.98.1-bookworm. The tag names Rust 1.98.1 explicitly, so the compiler version is stated in the Dockerfile, although the latest prefix is not a fixed image version. The same Dockerfile also carries a note about using the bookworm base image to match the GPU runtime image, because a libc version mismatch was producing runtime errors, which is a good illustration of where these version surfaces collide. If you build images yourself, treat the toolchain tag as something you pin.

Qdrant Edge is not a small server, it is a library inside your process

The second runtime is structured differently enough to be its own decision. Qdrant Server is client-server. Qdrant Edge is described as a lightweight version for edge devices and resource-constrained environments that, unlike the server, runs inside the application process, storing and querying data locally and able to synchronise with a Qdrant server. In Python you create a shard rather than a client:

from qdrant_edge import Distance, EdgeConfig, EdgeVectorParams, EdgeShard, Point, UpdateOperation

shard = EdgeShard.create("./shard", EdgeConfig(
    vectors={"my-vector": EdgeVectorParams(size=4, distance=Distance.Cosine)}
))
shard.update(UpdateOperation.upsert_points([
    Point(id=1, vector={"my-vector": [0.1, 0.2, 0.3, 0.4]}, payload={"color": "red"})
]))

The shard exposes methods to manage data, query it and restore snapshots, so the concepts carry over, but the object graph does not, and EdgeShard takes a directory path where the server takes a URL. The page does not describe how synchronisation with a server behaves when the two diverge, so if you start on Edge for a desktop or embedded application, plan the reconciliation yourself.

Eight clients, and portability rests on a published OpenAPI specification

Six client libraries are official: Go, Rust, JavaScript and TypeScript, Python, .NET with C#, and Java. Two more are community maintained, Kotlin and PHP, which is the distinction that matters when you pick one, because the project does not carry their compatibility. The real portability answer sits underneath the client list. The REST API is defined by an OpenAPI 3.0 specification served at api.qdrant.tech, and the raw definitions are committed in the repository at docs/redoc/master/openapi.json, so a client can be generated for nearly any language from the spec itself rather than hand-written. On top of REST there is a gRPC interface, which the page positions for faster, production-tier searches. That gives you an axis the client list does not: you can be on an official client and still choose REST or gRPC, and you can be on no client at all. The repository reflects the same split, with an openapi directory at the top level next to the Rust crates.

A Cargo workspace where master sits ahead of the newest release tag

The repository root shows the shape of the project: Cargo.toml and Cargo.lock at the top, then src, lib, pkg, tools, tests, docs, openapi and config directories, alongside clippy.toml, rustfmt.toml, shell.nix and a .rusty-hook.toml. Lint configuration is inherited from the workspace through a lints section with workspace set to true, and the manifest sets default-run to qdrant, which fixes the binary name. The version story is tidy and worth noting precisely. The manifest declares 1.20.0, which matches the newest release tag, v1.20.0, published on 2026-10-22, after v1.19.2 on 2026-10-05 and v1.19.1 on 2026-09-04. The last push to master is dated 2026-11-02, so the default branch is slightly ahead of that tag. Building master therefore gives you code that no release has shipped, which is fine for development and wrong if you need to name the exact revision you audited.

Editorial conclusion

Use it when you need filtered vector search at scale and you are willing to own an authenticated, backed-up service, and pick the server or the in-process Edge build based on whether you are deploying a service or embedding the index in an application. Do not expose the quick start container as it is documented to run, because it has no authentication and listens on all network interfaces. Before you commit, decide whether you need GPU acceleration, since that is a build-time choice, and pin a release tag rather than the master branch when reproducibility matters.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes