What Sets Them Apart
Both extensions live inside Postgres and let SQL queries do vector similarity search, so the boundary between them feels blurry until a workload actually grows. pgvector is the path-of-least-resistance default — broadly supported by managed Postgres providers, simple to install, and adequate for the first few hundred million embeddings. VectorChord is purpose-built for the next order of magnitude, with index designs and quantization techniques that keep recall high and memory low where pgvector starts to struggle.
VectorChord and pgvector at a Glance
pgvector is the original Postgres vector extension and now the de facto baseline. It supports HNSW and IVFFlat indexes, runs on every major managed Postgres service (RDS, Aurora, Neon, Supabase, Cloud SQL), and is mature enough that documentation, tutorials, and operational war stories are everywhere. For most teams adding vectors to a relational app, pgvector is the right starting point and often the right ending point too.
VectorChord, from TensorChord, is the second-generation extension built on lessons from pgvecto.rs. It is written in Rust, uses IVF indexes paired with RaBitQ quantization, and targets the workloads where pgvector forces a migration to a dedicated vector DB. Where pgvector aims for ubiquity, VectorChord aims for scale: billion-vector indexes that fit in reasonable memory, with recall that holds up under filters.
Both are open source and both are Postgres-native, so neither forces a second database. The difference is what happens at the scale ceiling — pgvector's curve gets steep where VectorChord's stays flatter.
Performance Ceiling and Recall Behavior
RaBitQ quantization is the technical wedge. Where pgvector's IVFFlat and HNSW implementations either hold full-precision vectors (memory-hungry) or use simpler quantization (recall-degrading), RaBitQ delivers near-full-precision recall at a fraction of the memory cost. For workloads with hundreds of millions to billions of embeddings, that's the difference between fitting on one well-provisioned Postgres instance and requiring a horizontal vector-DB migration.
Filtered search is where the gap widens further. Both extensions support filtering, but VectorChord's index design is more deliberate about staying performant when vector similarity and metadata filters combine — the workload pattern that dominates multi-tenant SaaS and time-windowed retrieval. pgvector handles this acceptably for moderate scale but degrades faster as filter selectivity drops.
At small scale, the difference is invisible. Below ~10M vectors, both extensions are fast enough that the choice does not matter for end-user latency. The interesting question is what shape of workload the team expects to grow into over the next 18 months, not what shape it is in today.
Operations, Ecosystem, and Risk
pgvector wins on ubiquity and ecosystem. Every managed Postgres provider supports it, monitoring tools recognize it, and the community of operators who have deployed it is enormous. Risk is well-understood. For teams that prefer the path with the most well-mapped trail, pgvector remains the safer pick.
VectorChord requires more operational deliberation. Managed provider support is improving but uneven, the community is smaller, and some operational corners are newer. The upside is a real ceiling raise — the migration to a dedicated vector DB that pgvector users plan for at year two often becomes unnecessary. For teams that already operate Postgres seriously and want to keep doing so at scale, that's a meaningful win.
The Bottom Line
Choose pgvector for new projects, smaller workloads, and teams that prioritize ecosystem and managed-service support. Choose VectorChord when the workload will plausibly hit pgvector's scale ceiling, when keeping everything in Postgres is operationally important, and when the team is comfortable adopting a newer-but-credible extension. Both are open source — neither choice is permanent, but VectorChord saves a migration that pgvector users frequently end up doing.