Most vector database documentation is written to get you to a working demo in five minutes and then stops, on the reasonable assumption that a demo is what you came for. This does that too, and then it keeps going into the material that determines whether the thing survives contact with real data, which is why I rate it well and also why people find it harder than the alternatives. Start with the good part, which is the treatment of index types. There is a genuine engineering decision behind every vector search system, which is that you are trading recall for speed and memory, and the shape of that trade depends on which index you build and how you configure it.
The documentation explains the families properly. Flat search for exact results at small scale, inverted file approaches that cluster vectors and search only nearby clusters, graph based indexes that give excellent speed at a memory cost, and the quantised variants that shrink memory at a cost to precision. It tells you what each one costs and what it gives you. I have read a lot of documentation in this category and most of it lists the index names and moves on, leaving you to discover through production incidents that your recall is quietly terrible.
This does not do that, and if you are choosing any vector store, these pages are worth reading even if you then choose a different product. Getting started is easy now, which was not always true. The lightweight embedded mode installs with a package manager and runs inside your process with no containers and no cluster, so you can build something and see whether the approach works before you commit to any infrastructure. That path did not exist in the early days and its absence made the project much harder to evaluate than it needed to be.
Filtering is handled seriously. The problem of combining a vector similarity search with structured predicates, so you get the nearest neighbours among the documents this particular user is allowed to see, is where a lot of naive implementations fall apart, and the documentation explains both the query syntax and what the filter does to your recall and latency. That second part is the part people skip and it is the part that matters. Now the difficulties.
The distributed architecture has a lot of moving parts. Separated components for coordination, query, data and indexing, with a message queue underneath and object storage behind it. That design is why the thing scales to volumes that would flatten simpler systems, and it means that running it yourself is a genuine operational commitment rather than a container you start and forget. The docs describe this accurately, and no amount of good writing makes a system with that many components simple to operate.
The distance between the easy local mode and a real cluster is the biggest practical problem. You build happily against the embedded version, everything works, and then production requires an entirely different deployment with different operational characteristics and different failure modes. The documentation covers both ends and does less than it should to prepare you for the journey between them. Version drift is a persistent irritation.
The project has moved fast, the API has changed across major versions, and searching for an answer will surface pages and community posts written against an older release. Some of the advice you find will be subtly wrong for the version you are running, and working out which is your problem rather than theirs. Commercially, the managed service is always in view. It is mentioned wherever the self hosted path becomes work, which is honest in the sense that the managed option genuinely is easier, and it is still a sales funnel and reads like one.
And the largest caveat is one of fit. Most teams reading these pages have a few hundred thousand vectors, or a few million, and will never approach the scale that justifies this architecture. At that size a simpler store, or a vector extension to the database you already run, will serve you better and cost you less attention. Choosing this because it scales to billions when you have thousands is a decision you will pay for in operational overhead every week.
My three point seven is for documentation that teaches the actual engineering better than its competitors, marked down for a complexity it can describe but not remove, for version churn that makes searching for answers unreliable, and for being the right answer to a question most readers do not have.