Vector databases attract terrible documentation. The usual pattern is a quickstart that embeds three sentences, runs a similarity search, returns the obvious answer, and declares the topic covered. Qdrant's documentation is meaningfully better than that, mostly because it treats retrieval as an engineering discipline with real tradeoffs rather than a solved step. The tiered tutorial structure is the right shape.
Basics for people who need to understand what a vector search actually is, search engineering for the techniques that matter once your corpus is not three sentences, then operations and scale for running it properly. That progression matches how people actually hit problems and it means you can find your level rather than reading everything. The filtering and payload material is the most valuable part. Every naive vector search implementation eventually discovers that pure similarity is not enough.
You need results from this tenant, from the last six months, in this language, from documents this user can see. Combining filters with vector search is genuinely hard, because the obvious approaches either filter after retrieval, which returns too few results, or filter before, which is slow. Qdrant's approach to filterable indexes is explained properly here, including where it degrades. That discussion exists in very few places and it is where most production retrieval problems originate.
Hybrid search gets serious treatment. Dense embeddings capture meaning and miss exact terms. Sparse retrieval catches keywords, product codes, names and acronyms and misses meaning. Almost every real system needs both, and the documentation covers running them together and fusing the results rather than pretending one is sufficient.
Anyone whose search inexplicably fails on part numbers is failing to read this section. Quantization documentation is honest in a way vendor docs often are not. Compressing vectors saves an enormous amount of memory and costs you some accuracy. The docs say so, quantify roughly what you lose at each level, and explain the rescoring approach that recovers most of it.
That framing, here is the tradeoff and here is how to measure whether it hurts you, is what I want from technical documentation. Multitenancy is covered and almost nobody covers it. If you serve multiple customers from one deployment you need isolation that is genuinely enforced and does not require a separate collection per tenant, and the guidance here is practical. Running locally in Docker with no account is the right default for learning.
You can work through the whole basics tier without giving anyone your email. Now the gaps. Embeddings are almost entirely out of scope. The documentation will help you store and search vectors and it will not help you decide which embedding model to use, why one performs better on your domain, whether to fine tune, or how chunking strategy interacts with retrieval quality.
Those decisions determine whether your search works far more than any database setting does. FastEmbed is documented as a convenience, which is not the same as teaching you what embeddings are doing. Related and more serious, there is nothing about evaluating retrieval quality. You can follow every page here, build a technically excellent deployment, and have no idea whether it returns the right documents.
Recall at k, mean reciprocal rank, building a labelled test set, these are absent. A section on measuring whether your retrieval works would be the single biggest improvement to this documentation. The commercial pull has grown. The cloud offering appears more prominently with each revision and some newer features arrive there first.
The open source version remains genuinely capable, and the direction is visible. Some tutorials quietly assume a particular embedding provider or stack, and swapping it out requires more adaptation than the page implies. Performance tuning is spread across the user manual, the tutorials and various blog posts rather than collected in one place, so optimising a slow deployment involves more searching than it should. My three point nine is for documentation that teaches the engineering of retrieval rather than just its own API, with genuinely useful material on filtering, hybrid search and quantization, marked down for leaving embeddings and evaluation almost untouched, scattered performance guidance, and a steadily firmer push towards the managed product.
Read the search engineering tier regardless of which database you end up using.