There is a pattern I have watched play out repeatedly over the last couple of years. A team builds something that needs retrieval, reads a few articles, concludes that they need a vector database, evaluates three of them, picks one, and now operates two data stores where they used to operate one. Their embeddings live in the new one and everything else, including all the metadata they need to filter on, lives in Postgres. Every query now involves both, the consistency story is now their problem, and the operational surface has roughly doubled.
A meaningful fraction of those teams had a few hundred thousand vectors and would have been entirely fine with an extension. This is that extension, and the documentation is refreshingly free of any attempt to talk you into anything. It is a README. It tells you what the types are, what the distance operators are, what the two index types do, and how to create them.
There is no landing page with logos, no comparison table that mysteriously favours the author, and no whitepaper. For a project that could easily have gone the other way, the restraint is worth noting. The genuinely educational content is the index discussion. You get two choices.
The inverted file approach partitions vectors into lists and searches a subset, which builds quickly, uses modest memory, and requires you to have data present before you build it because the partitions are derived from the data. The graph approach builds a navigable structure, gives better recall for a given speed, costs considerably more memory, and takes much longer to build. The documentation states this plainly and tells you the parameters that move the trade in each direction. That is the whole decision, laid out in a few paragraphs, and it is more useful than most vendor comparison content of any length.
The filtering discussion is the part I would highlight, because it addresses the thing that actually goes wrong. People assume they can apply a WHERE clause alongside a vector search and get the nearest neighbours that satisfy the condition. What can happen instead is that the index returns its candidates first and the filter then removes most of them, leaving you with fewer results than you asked for and worse ones than exist. This surprises people in production.
The documentation warns you about it and describes the approaches available. That warning is worth the read on its own. The structural advantage is one the docs mention only lightly, and it is the strongest argument for this whole approach. Your vectors sit in the same database as everything else.
You can join them to your users table. You can filter on tenant, on date, on status, using the same query planner and the same indexes you already have. Your writes are transactional. Your backups already cover it.
Your access control already covers it. Nobody has to learn a second system. For the majority of applications that is a decisive advantage and it disappears the moment you split your data across two stores. Now the limits.
This is documentation for people who already know Postgres well. It assumes you are comfortable with index creation, with query plans, with the memory settings that govern index builds. If you are not, you will find it terse to the point of unhelpful, and you will need to go and learn Postgres properly, which is good advice anyway. Tuning the index builds is fiddlier than the page suggests.
Build times for the graph index on a large table can be long enough to be a genuine operational problem, and the memory settings that govern it interact with settings elsewhere in your configuration. The documentation gives you the knobs and not much sense of how they feel in practice. And there is nothing about where this stops working. At some scale a dedicated system genuinely is the right answer, and a reader gets no help identifying whether they are approaching that point.
It would not take much to say something useful here and it is not said. My four point one is for concise, accurate, unmarketed documentation for a piece of software that quietly removes a whole category of unnecessary architecture from a great many projects, with an unusually candid treatment of the filtering trap. Marked down for assuming a level of Postgres fluency it does not help you reach, for thin tuning guidance, and for silence on its own ceiling. Read it first, and buy a vector database only after you can say why this one is not enough.