Vector search used to mean bolting a separate database onto your stack. Two open-source PostgreSQL extensions have changed that: pgvector and pgvectorscale. Both are free, both run inside Postgres, and both have shipped meaningful upgrades in the past year — pgvector is at v0.8.6 with iterative index scans and half-precision vectors, while pgvectorscale 0.9.0 added PostgreSQL 18 support and concurrent index builds. If you are building RAG pipelines, semantic search, or recommendation features, the choice between them affects your memory budget, your recall, and your operational complexity. Here is the practical comparison, with a default recommendation.

What pgvector gives you

pgvector is the community-standard extension for embeddings. It is a single CREATE EXTENSION away, needs no extra services, and supports four vector types: vector (single precision), halfvec (half precision, up to 4,000 dimensions), bit (binary), and sparsevec (up to 1,000 non-zero elements).

For indexes you get two options. HNSW builds a multilayer graph with the best speed-recall tradeoff and no training step — you can create it on an empty table. IVFFlat builds faster and uses less memory, but needs a lists parameter and a populated table. Since 0.8.0, pgvector also ships iterative index scans, which fix the classic problem where filtered queries silently return too few results because filtering happens after the approximate scan.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  title text,
  embedding vector(1536)
);

-- HNSW index for cosine distance
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- Keep filtered queries from dropping results (pgvector 0.8.0+)
SET hnsw.iterative_scan = relaxed_order;

What pgvectorscale adds

pgvectorscale, built by Timescale, layers on top of pgvector’s types — your vector columns and query syntax stay identical. Its headline feature is the StreamingDiskANN index, inspired by Microsoft’s DiskANN research. Instead of holding the graph and vectors in RAM, it streams from disk, and its memory_optimized storage layout uses Statistical Binary Quantization (SBQ) to compress vectors. That is how teams index tens of millions of embeddings without a cluster-sized memory bill. It also supports label-based filtered search based on Microsoft’s Filtered DiskANN work, which keeps recall high when you filter by category, tenant, or document type.

CREATE EXTENSION IF NOT EXISTS vectorscale;

-- StreamingDiskANN: disk-based ANN index, SBQ-compressed by default
CREATE INDEX document_embedding_idx ON documents
  USING diskann (embedding vector_cosine_ops);

-- Label-filtered search: put the label column in the index
CREATE INDEX ON documents
  USING diskann (embedding vector_cosine_ops, category_id);

Version 0.9.0 (November 2025) added PostgreSQL 18 support, dropped PostgreSQL 13, and introduced concurrent index builds; 0.8.0 fixed several crash bugs under concurrent inserts. One operational note: DiskANN builds are memory-intensive, so raise maintenance_work_mem when building large indexes.

Head to head: which should you pick?

Start with pgvector when: your dataset fits in memory (roughly up to a few million embeddings), you want the most widely documented path, or you value zero extra concepts in your schema. HNSW plus iterative scans is genuinely good for most production workloads.

Reach for pgvectorscale when: embeddings outgrow RAM, you are at 10M+ vectors, memory cost is a real line item, or you need filtered vector search at scale. Because it is syntax-compatible with pgvector, migrating later is a low-risk CREATE INDEX ... USING diskann swap rather than a rewrite.

A Houston lens

Houston’s biggest industries are document businesses. Energy companies search P&IDs, well logs, and safety manuals; healthcare systems retrieve clinical notes; logistics firms query maintenance records across fleets. A typical pattern: embed the documents with an LLM or embedding model, store vectors in Postgres, and serve a RAG-style Q&A over the corpus. For an energy services firm with tens of millions of inspection records, pgvector + halfvec + HNSW is a fast first win; when that corpus doubles and the memory bill follows, StreamingDiskANN is the natural next step — same table, same queries, smaller footprint.

-- The query is identical regardless of which index backs it
SELECT id, title, 1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 10;

Bottom line

Default to pgvector. It is simpler, ubiquitous, and covers most workloads with HNSW plus iterative scans. Adopt pgvectorscale when memory becomes the constraint — its StreamingDiskANN index is the strongest reason to scale Postgres as a vector database without adding a separate system. Whichever you choose, measure recall@10 on your own data before trusting any benchmark, and keep both in mind: they are complements, not rivals. For a deeper dive, Timescale’s pgvector vs pgvectorscale comparison is a good follow-up read.