pgvector vs Cloudflare Vectorize: where each one actually fits

Vector search has become a baseline capability for any app doing RAG (retrieval-augmented generation), semantic search, or recommendation. The two cleanest options in 2025 for mid-scale workloads: pgvector (Postgres extension) and Cloudflare Vectorize (managed vector DB on the Cloudflare platform). After running both on real RAG workloads, here is the working decision matrix.

The short answer

Use case	Pick
You already use Postgres heavily	pgvector
You ship on Cloudflare Workers	Vectorize
You need vectors + structured queries in the same database	pgvector
You need globally-distributed reads with edge latency	Vectorize
You self-host and want full control	pgvector
You want zero ops	Vectorize
Sub-50ms search at scale on the edge	Vectorize
Complex joins between vectors and relational data	pgvector

pgvector

A Postgres extension that adds a vector column type and similarity-search operators. Mature, well-tested, ships on most managed Postgres providers (Supabase, Neon, AWS RDS, Cloudflare Hyperdrive, etc.).

What it wins on:

• Co-located with your relational data. You can JOIN against vectors. “Find articles similar to X that are also published in the last week and have tag Y” is one SQL query.
• Single source of truth. Your app already has Postgres. Adding pgvector means one fewer system to operate.
• Mature tooling. Indexes (IVFFlat, HNSW), tuning knobs, observability — all the Postgres tooling works
• Works with any Postgres host. Vendor-neutral.

Where it loses:

• Scaling limits at very high dimensions / very high QPS — pgvector is good but not specialised. At 100M+ vectors with high query load, dedicated vector DBs win.
• Index build times can be long for big tables. Building an HNSW index on 10M rows is hours.
• The 869-upvote “You just need postgres” thread is the community pitch — but the Case Against PGVector counter-thread is also worth reading. There’s nuance.

Cloudflare Vectorize

A managed vector database that runs on Cloudflare’s edge network. Designed to integrate cleanly with Workers + D1.

What it wins on:

• Edge latency. Vector search from a Worker in under 50ms — nothing pgvector can match unless you also run on Cloudflare.
• Zero ops. No index tuning, no Postgres maintenance, no scaling decisions.
• Tight Workers integration. Bindings, no connection pooling, no cold-start overhead.
• Pricing model. Pay-as-you-go, free tier supports real side projects.

Where it loses:

• Vector-only. No joins with structured data. If you need “vectors + metadata + complex filtering,” you do that join in application code or store both Vectorize + D1.
• Cloudflare lock-in. Migrating off Vectorize means switching to pgvector or Pinecone or Weaviate — non-trivial.
• Smaller community / fewer tutorials than pgvector.
• Newer product. Edge cases still emerge.

The practical decision matrix

Use pgvector if:

• You already have Postgres in your stack
• Your queries combine vectors and structured data
• You need cross-vendor portability
• You have an existing ops team for Postgres
• Dataset is under 10M vectors (above that, consider dedicated)

Use Vectorize if:

• You ship on Cloudflare Workers
• Edge latency is a real product requirement
• You don’t want to operate Postgres
• Your workload is pure vector search (or vectors + simple metadata)

Use neither (consider Pinecone / Weaviate / Qdrant) if:

• You have 100M+ vectors
• You need rich filtering / hybrid search at scale
• You’re willing to add a specialised system

How to actually set up pgvector

In a Postgres database:

CREATE EXTENSION vector;

CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  body TEXT NOT NULL,
  embedding vector(1536)  -- dimension matches your embedding model
);

-- Add an HNSW index for fast approximate search
CREATE INDEX ON articles USING hnsw (embedding vector_cosine_ops);

Query:

SELECT id, title FROM articles
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 10;

That’s it. The <=> operator does cosine distance search using the HNSW index.

How to actually set up Vectorize

wrangler vectorize create my-index --dimensions=1536 --metric=cosine

In wrangler.jsonc:

{
  "vectorize": [
    { "binding": "INDEX", "index_name": "my-index" }
  ]
}

In your Worker:

await env.INDEX.upsert([
  { id: 'article-1', values: [0.1, 0.2, ...], metadata: { title: 'X' } }
]);

const matches = await env.INDEX.query([0.1, 0.2, ...], { topK: 10 });

The bigger pattern

Vector search has matured to “boring infrastructure” status in 2025. Both pgvector and Vectorize are reliable, well-documented, production-viable. The choice is mostly architectural — which platform / database you’re already on.

For TopInsight, we’ll likely use Vectorize when we add semantic search across articles (we’re on Cloudflare). For a Postgres-shaped project, pgvector is the answer.

For the broader database choice, see our Neon vs Supabase vs PlanetScale piece. For the Cloudflare D1 context, Workers + D1 production guide.