Search "vector search in Postgres" and you get three package names — pgvector, pgvectorscale, pgai — presented like a bracket you have to pick a winner from. It is the wrong mental model. They are not three answers to one question; they are three floors of one building, each assuming the one below it. Read them as a stack and the choices get clearer — including the choice that just got made for you.
The foundation: pgvector
vector type, HNSW/IVFFlat indexes, and distance operatorspgvector, Andrew Kane's independent extension, is the bedrock everything else stands on. It adds the vector column type, the distance operators (<-> for L2, <=> for cosine, <#> for inner product), and two approximate-nearest-neighbor indexes: IVFFlat (cluster-then-search) and HNSW (a navigable small-world graph). With it, embeddings live in the same database as your rows, inside the same transactions, reachable from the same WHERE clause and JOIN.
The limit is honest and structural: HNSW is a graph index that wants to live in RAM. It is fast and accurate, but as your vector count climbs into the tens of millions, the memory to keep that graph hot — and the bill for that memory — climbs with it. That is not a flaw; it is just the ceiling of the foundation. Which is exactly the gap the next floor was built to fill.
The scale floor: pgvectorscale
pgvectorscale's own one-liner is the tell: it calls itself a complement to pgvector, not a replacement. It requires pgvector and adds two things aimed squarely at the RAM ceiling. The first is StreamingDiskANN, an index inspired by Microsoft's DiskANN research that is designed to serve ANN search with much of the index on SSD rather than in memory — so a billion-scale corpus does not demand a memory-heavy box. The second is statistical binary quantization (SBQ), a compression scheme that shrinks the vectors so more of them fit in less space. It is written in Rust via the pgrx framework, which is its own quiet signal about where serious Postgres extension work is heading.
How much does it buy? Timescale's own benchmark claims pgvector-plus-pgvectorscale hit roughly 28x lower p95 latency, 16x higher throughput, and 75% lower cost than Pinecone at 50 million 768-dimensional vectors and 99% recall. Read that with the caveats it earns: it is a vendor benchmark, run by the seller, against Pinecone's storage-optimized s1 tier (not its latency tier), and the cost line compares self-hosted EC2 against fully-managed Pinecone — so it omits the labor of operating it yourself. The direction is plausible and the mechanism is real; the decimals are marketing.
The floor that fell off: pgai
The top floor was the most ambitious and is now the cautionary one. pgai's Vectorizer tried to delete your ingestion service entirely: point it at a source table and it would chunk, embed, and — the genuinely hard part — keep the embeddings in sync as rows changed, with queuing and retries against flaky embedding APIs, the way an index stays current as data mutates. It ran on plain Postgres 15+, no TimescaleDB required.
It is also, per its own README as of February 2026, no longer being maintained or supported. That is the load-bearing fact of this whole comparison, and it is more instructive than any benchmark. The two lower floors — the vector type and the scale index — are stable infrastructure with clear, narrow jobs. The embedding-sync layer, the one trying to own your data pipeline inside the database, is the contested one, and the first to be abandoned. (For context: Timescale rebranded to TigerData in mid-2025, though the GitHub org is still timescale/.)
How to read the stack
The real decision was never "which of these three." It is how far up the stack you can stay inside Postgres before a dedicated engine earns its keep. Today the answer is clean: pgvector for the type and indexes, pgvectorscale when your vector count makes HNSW's RAM hurt — both active, both under the permissive PostgreSQL License. The pgai layer is where the Postgres-native frontier currently stops: the pattern is worth stealing, the package is not worth adopting fresh. Do your embedding and chunking in your application, write the vectors into pgvector, and you have a stack that is boring in exactly the way infrastructure should be.
If you are still deciding whether to stay in Postgres at all, that trade-off — consistency and one system versus a purpose-built vector database — is its own piece. But the Postgres ceiling is higher than the "vs" framing suggests, as long as you climb the stack in the right order.
Repository descriptions, maintenance status, and licenses are drawn from each project's GitHub repository; star counts are live-page snapshots as of 2026-06-22 and drift daily. The Pinecone comparison is a vendor-run benchmark, flagged as such.
