# pgvector

55 Hacker News commenters recommended pgvector and 20 criticized it, November 2025 to November 2026. It was recommended in 10 of 13 months. It meets the Hacker Approved badge rule.

**Verdict:** People recommend it as an easy way to add vector search inside PostgreSQL, avoiding a separate database; critics say it struggles with very large, fast-changing indexes.

## Why people recommend it

- Fast enough for many workloads (5 comments): "pgvector HNSW indexes (m=64, ef_construction=200) give you sub-100ms semantic search without leaving Postgres" ([source](https://news.ycombinator.com/item?id=46022853)) "Even without fancy indexing, a full scan (1 search vector -> 5M stored vectors), takes less than 40ms." ([source](https://news.ycombinator.com/item?id=45800957)) "have seen very fast lookups with pgvector (HNSW index) and sqlite-vec on 20k vectors" ([source](https://news.ycombinator.com/item?id=46848428))
- Easy to set up and use (4 comments): "you can just add the pgvector extension determine what embeddings that you want to use and try it out without committing to much" ([source](https://news.ycombinator.com/item?id=46011324)) "I was genuinely surprised just how easy it was to get a fully working RAG set up with Postgres." ([source](https://news.ycombinator.com/item?id=47297475)) "surely the easiest solution is to run `CREATE EXTENSION vector`" ([source](https://news.ycombinator.com/item?id=47297261))
- Keeps vectors next to relational data (4 comments): "PostgreSQL with pgvector now supports HNSW indexing, meaning you can keep your vectors right next to your relational data." ([source](https://news.ycombinator.com/item?id=47204524)) "if you're already running postgres with pgvector, you're in a good spot" ([source](https://news.ycombinator.com/item?id=47297369)) "pgvector could handle their use case with less operational overhead" ([source](https://news.ycombinator.com/item?id=47257022))
- Works for hybrid text and vector search (4 comments): "I've been doing some RAG prototypes with hybrid search using pg_textsearch plus pgvector and have been very pleased with the results." ([source](https://news.ycombinator.com/item?id=47593836)) "pgvector + tsvector (for hybrid search) seems like the most logical MVP" ([source](https://news.ycombinator.com/item?id=46029022)) "hybrid search ( plpgsql_bm25 + pgvector ) with Reciprocal Rank Fusion" ([source](https://news.ycombinator.com/item?id=49371344))

## What people warn about

- Scaling limits at very large sizes (4 comments): "the limitations of pgvector are very real when you're talking indices that grow beyond millions of things" ([source](https://news.ycombinator.com/item?id=45805496)) "found Postgres to be unsuitable at several orders of magnitude less than we currently have" ([source](https://news.ycombinator.com/item?id=45805087)) "pgvector just doesn't really scale to the kinds of workloads we ran here" ([source](https://news.ycombinator.com/item?id=46136868))
- Struggles with high-velocity inserts (3 comments): "But they’re all workarounds for the fact that pgvector wasn’t really designed for high-velocity real-time ingestion." ([source](https://news.ycombinator.com/item?id=45800808)) "Postgres isn't built from the ground-up for high-velocity vector insertions" ([source](https://news.ycombinator.com/item?id=45806693)) "can support 15x more updates per second comparing to pgvector's HNSW" ([source](https://news.ycombinator.com/item?id=45799401))
- Index rebuilds and high memory use (3 comments): "Vacuuming is grief enough. Rebuilding the index sounds like more of a nightmare than with Solr/Lucene." ([source](https://news.ycombinator.com/item?id=45816869)) "IVFFlat indexes have to be periodically rebuilt, that HNSW has high overhead" ([source](https://news.ycombinator.com/item?id=45808721)) "HNSW index on a few million vectors can consume 10+ GB of RAM or more" ([source](https://news.ycombinator.com/item?id=45800752))
- Hard to predict filtering behavior (2 comments): "pg_vector's economics can be much worse, especially in multi-tenant scenarios" ([source](https://news.ycombinator.com/item?id=46721958)) "it's hard to predict when postgres will decide to use pre- vs post-filtering" ([source](https://news.ycombinator.com/item?id=45800596))

## Alternatives hackers recommend

- [PostGIS](https://hackerapproved.com/p/postgis.md): 20 recommend
- [pg_lake](https://hackerapproved.com/p/pg-lake.md): 18 recommend
- [ParadeDB](https://hackerapproved.com/p/paradedb.md): 13 recommend
- [pg_textsearch](https://hackerapproved.com/p/pg-textsearch.md): 10 recommend
- [Tin full-text search for Postgres](https://hackerapproved.com/p/tin.md): 10 recommend

## Cite as

Hacker Approved, "pgvector", https://hackerapproved.com/p/pgvector/ (counts from 1,795,640 Hacker News comments, November 2025 to November 2026).
