pgvector vs Cloudflare Vectorize — where each one actually fits

Both pgvector and Cloudflare Vectorize do vector search. They optimize for fundamentally different shapes of problem. After running both in production through 2024-2025, the decision is almost always determined by your application architecture, not by performance benchmarks.

Theo”s July 4 video — “I finally switched to Postgres.” — captured the broader “consolidate to boring infrastructure” sentiment that shaped how engineers thought about vector search in 2025. If you”re already on Postgres, pgvector is the answer to most vector-search needs. If you”re building edge-first on Cloudflare Workers, Vectorize is the answer. The interesting cases are the ones that don”t obviously fit either pattern.

The r/Rag “Who here has actually used vector DBs in production?” thread (71 upvotes, August 24) — a month before this article — captured the canonical practitioner perspective. The top comment (34 upvotes):

“We”re using Qdrant for 180k documents and while it works well, I came to realize vector stores are mostly stupid. So, we”re transitioning to pgvector.”

That sentiment — “vector stores are mostly stupid, use pgvector” — has been gaining traction through 2025. Reasons matter; the consolidation pattern is real.

What pgvector actually is

pgvector is a Postgres extension that adds vector data types and similarity search. Install it; create a column of type vector(1536) (or whatever your embedding dimension is); query with <=> (cosine distance), <#> (negative inner product), or <-> (Euclidean distance) operators.

The pitch:

• You already have Postgres. No new database service to operate, monitor, back up, secure.
• Real SQL. Join vector results with relational metadata in one query. No “first fetch IDs from vector DB, then fetch records from Postgres” two-step.
• Mature. Used by Supabase, Neon, AWS RDS, Azure Database for PostgreSQL. Battle-tested.
• Free. No per-query pricing; runs on your existing Postgres instance.
• Indexes: HNSW for approximate search, IVFFlat for some workloads.

What Cloudflare Vectorize actually is

Vectorize is Cloudflare”s edge-native vector database, accessed via Workers API. Create an index; insert vectors with metadata; query for nearest neighbors.

The pitch:

• Edge-native. Queries run at Cloudflare”s edge, low latency globally.
• No infrastructure to manage. Cloudflare runs it; you make API calls.
• Tight Workers integration. If you”re building on Cloudflare Workers, Vectorize is the natural fit.
• Per-query pricing. Cheap for low-volume; predictable scaling.
• Limits: 5M vectors per index in mid-2025; metadata filtering on small set of fields.

The decision matrix

Pick pgvector if:

• You”re already running Postgres for your main app
• You need to join vector results with relational data
• Your data is in the hundreds-of-thousands to low-millions scale
• You want to avoid adding a new database service
• You”re cost-sensitive at scale (pgvector is “free” if you”re paying for Postgres anyway)
• You need transactional consistency between vectors and metadata

Pick Cloudflare Vectorize if:

• You”re building on Cloudflare Workers
• You need global edge-distributed vector search
• Your main app doesn”t use Postgres (no consolidation gain)
• You want zero-ops vector infrastructure
• Your scale is small-to-medium (under 5M vectors per index)
• You don”t need complex joins between vector results and relational data

Don”t pick either if:

• You need 10M+ vector scale (consider Qdrant, Weaviate, Milvus, or pgvector with serious tuning)
• You need exotic distance metrics or filtering
• You”re doing computer-vision-scale vector workloads (specialized GPU-accelerated tools win)

The r/Rag practitioner perspective

The r/Rag thread captures the consultant-side view. The OP — who”d built RAG systems with OpenSearch, Elasticsearch, and Pinecone — was migrating to pgvector for new work. The consultant pattern: vector-DB-as-service products solve a problem most apps don”t actually have at their scale.

Top comments and the broader thread:

• “180k documents on Qdrant works well, transitioning to pgvector” — 34 upvotes
• “I use postgres pgvector for my SaaS, working well… support pdf, text, docx” — 11 upvotes
• The pattern: for documented-scale RAG (thousands to hundreds-of-thousands of vectors), pgvector handles it without ceremony.

The r/mcp “10 MCP memory servers/frameworks” thread (97 upvotes, September 6) extends the pattern into the agent-memory space. For agent memory specifically, lighter-weight vector-store options (including in-Postgres pgvector) are increasingly the default over specialized vector databases. Agents don”t need 100M-vector scale; they need fast, cheap, transactional vector queries.

The Cloudflare ecosystem context

Christian Lempa”s July 18 video — “Publish a Static Hugo Website the EASY way // Cloudflare Workers” — captures the broader “Cloudflare as default substrate” trend through 2025. If you”re building on Workers, Vectorize fits naturally. If you”re not, the consolidation argument is weaker.

The Workers + Vectorize + D1 + Workers KV stack is genuinely good for content sites, edge APIs, and lightweight AI applications. For these use cases Vectorize is the right call. For traditional SaaS apps with their own Postgres and managed-service infrastructure, the pgvector consolidation wins.

Lawrence Systems” “Forget Kubernetes, This Is How I Run my Docker Containers” (September 5) is the simplification thesis from the homelab side — most workloads don”t need the complexity. The vector-DB version: most RAG workloads don”t need Pinecone-grade infrastructure; pgvector with sensible indexes handles them.

Performance comparison (honest version)

The headline numbers most “vector DB benchmarks” report focus on edge cases that don”t match most workloads. The practical performance:

pgvector with HNSW index, 500K vectors, well-tuned:

• Single query: 5-20ms
• p99: 50-150ms
• Throughput: depends on Postgres instance size

Vectorize, similar scale:

• Single query: 30-80ms (includes edge round-trip)
• p99: 100-200ms
• Throughput: scales with Workers infrastructure

For pure raw speed: pgvector wins for backend-only apps; Vectorize wins for edge-deployed apps (where the geography of the query origin matters).

For total system latency: depends entirely on architecture. pgvector inside your VPC has near-zero network overhead; Vectorize has Cloudflare network overhead but no separate database round-trip in the Worker.

The Postgres-extension full-text context

The r/PostgreSQL “Down the rabbit hole with Full Text Search” thread (121 upvotes, June 1) is the broader signal — Postgres”s built-in capabilities for search (full-text, then vector with pgvector, then increasingly hybrid) keep expanding the set of workloads that don”t need a specialized search infrastructure. The “use the database you have” pattern wins more workloads each year.

The hybrid pattern that”s now common: Postgres full-text search (tsvector) for lexical matching + pgvector for semantic similarity, combined with weighted scoring in application code. Two indexes in one database; one query (or two in parallel); much simpler ops than running Elasticsearch + Pinecone separately.

Creator POV vs Reddit dissent

Theo”s POV through 2025 emphasizes consolidation — fewer tools, deeper investment in the ones you keep. Postgres + pgvector is a natural fit for this thesis.

The Reddit dissent through 2025 on r/Rag, r/PostgreSQL, r/CloudFlare:

The “use pgvector for everything” camp — growing. Particularly strong among SaaS builders with existing Postgres setups.

The “specialized vector DBs still win at scale” camp — accurate for 10M+ vector workloads. Qdrant, Weaviate, Milvus have distinct advantages above pgvector”s practical scale ceiling.

The “use Vectorize because you”re on Cloudflare” camp — small but growing as Cloudflare Workers adoption grows.

The “vector search is mostly stupid, use full-text” camp — present and surprisingly defensible. For many “search” use cases, well-tuned Postgres full-text search outperforms naive vector search on user-facing relevance.

What this means for working engineers in mid-September 2025

Three concrete positions:

1. If you”re already on Postgres, start with pgvector. Don”t add a separate vector DB unless you have a specific reason. The default-to-pgvector pattern matches where the industry is moving.

2. If you”re building on Cloudflare Workers, use Vectorize. Don”t fight the platform; the integration is the win.

3. If you”re evaluating from scratch for a new app, the decision is downstream of your platform choice. Pick the platform (Postgres-based vs Cloudflare-based) for app-architecture reasons, then use the vector tool that fits.

The honest critique

What this comparison doesn”t cover:

• Indexing strategy matters more than the vector DB choice. Bad HNSW parameters on pgvector underperform good defaults on Pinecone. The expertise to tune well is real.
• Embedding model choice matters more than vector DB choice. Bad embeddings make any vector DB useless. Get the embedding model right first.
• Hybrid search (vector + lexical) usually beats pure vector. Both pgvector and Vectorize support hybrid patterns; most production systems should use them.
• Cost at scale shifts the math. For 10M+ vectors with high QPS, specialized vector DBs become cost-competitive again. The pgvector-by-default pattern is for the practical-scale majority.

For most working engineers reading this in mid-September 2025: the “default to pgvector unless you have a specific reason” pattern is now the working consensus. Vectorize wins for Cloudflare-native apps; specialized vector DBs win for true large-scale or specialized workloads; everything else uses Postgres + pgvector. Optimize the embedding model and indexing strategy; the vector DB choice is rarely the bottleneck.

For the broader database choice context, see our Neon vs Supabase vs PlanetScale comparison and Cloudflare D1 read replicas analysis.