Vector Databases Compared

Your finance close runs in #finance. Stripe and QuickBooks reconciled, runway updated, posted Sunday night without you asking.

Engineering review lands in #eng. Viktor pulled the open PRs, left comments on auth-refactor, flagged a dependency blocking api-pagination.

Campaign brief lands in #growth: Meta CPA up 18%, recommendation to pause broad match, a draft landing page already deployed for the variant test.

You hired him on day zero. He lives in Slack and Microsoft Teams alongside your contractors and investors, connects to 3,000+ tools, pushes back when you ship something dumb.

"Viktor is now an integral team member, and after weeks of use we still feel we haven't uncovered the full potential." Patrick, Director, Yarra Web.

Get Started for Free

Every tab you open, every copy-paste into ChatGPT, every lost train of thought — that's your browser failing you. Norton Neo fixes it. Built-in AI works directly inside your session. Hover to preview. Search everything from one bar. VPN and ad blocking included, free.

Try Norton Neo Free

Your shiny new RAG pipeline works great on 10,000 vectors. Then you hit a million. Then ten million. Suddenly that "just use Postgres" advice from Hacker News doesn't feel so reassuring, and Pinecone's pricing page is giving you heart palpitations.

Let's break down the five vector databases you'll actually encounter in production. I'm skipping Milvus and Vespa, not because they're bad, but because 90% of teams evaluating vector DBs in 2024 to 2025 are choosing between these five.

pgvector is the "you already have Postgres" option. It's an extension, not a standalone database. You add it to your existing Postgres instance and suddenly you can store and query vectors alongside your relational data. No new infra, no new ops burden, no new billing page to cry over.

Pinecone is the fully managed, zero-ops option. You don't run anything. You send vectors, you query vectors, you pay the bill. It's genuinely good at what it does, but you're locked in tight.

Weaviate tries to be the "all in one" vector database. It has built-in vectorizers, GraphQL APIs, and a module system. It's powerful but opinionated.

Qdrant is the performance-obsessed option. Written in Rust, it's fast and memory-efficient. The API is clean, the filtering is excellent, and the community is growing fast.

Chroma is the "I just want embeddings to work" option. It started as a Python library for AI developers who didn't want to think about databases. It's lightweight, easy to start with, but limited at scale.

Everyone benchmarks differently, so let me give you numbers from the same benchmark suite (Tensoria, 2024) running ANN search on normalized embeddings with 768 dimensions.

A few things jump out:

Qdrant at 22ms P95 with 10M vectors is genuinely impressive. That's nearly half of Pinecone's 45ms at the same scale. If latency is your primary concern and you're willing to self-host, Qdrant is hard to beat.

pgvectorscale hitting 471 QPS at 50M vectors surprised a lot of people. The pgvectorscale project (by Timescale) adds a streaming disk-based ANN index that doesn't require your entire dataset to fit in RAM. That's a massive deal for cost-conscious teams.

Here's the catch though: raw benchmark numbers don't tell the whole story. In production, you're rarely doing pure vector similarity search. You're filtering by metadata, joining with relational data, and handling concurrent writes. That's where the differences get real.

This is the feature that separates "demo ready" from "production ready." You almost always need to filter vectors by some metadata before doing similarity search. Think: "find me similar products, but only in the Electronics category, priced under $50."

pgvector wins here by default because it's Postgres. You get the full power of SQL, joins, CTEs, window functions, whatever you need. Your metadata filtering is just a WHERE clause. No new query language to learn.

Qdrant's filtering is surprisingly good. It supports nested objects, typed fields, geo filters, and range queries. The filter engine is tightly integrated with the ANN index, so pre-filtering doesn't destroy your recall the way it does in some implementations.

Chroma falls short for anything beyond basic key-value filtering. It works fine for prototyping, but if your production queries involve complex metadata predicates, you'll outgrow it quickly.

Pinecone's filtering is solid but limited. It handles key-value metadata well, but there's no relational joins. If you need to cross-reference vectors with data in another table, you're making two API calls and stitching results together in your application code. That's fine at small scale, annoying at large scale.

This is where most blog posts get useless. They'll say "it depends" and move on. Let me give you actual numbers.

Monthly cost at 10M vectors (768 dimensions, ~100 QPS):

At 10M vectors, the cost differences are manageable. Most teams should just pick the hosted option and move on with their lives. The engineering time you save is worth more than the $20 to $90 difference.

But here's where it gets spicy. Monthly cost at 100M vectors:

That Pinecone number at 100M vectors, ~$3,200 per month, versus self-hosted Postgres at ~$835, that's a 3.8x gap. And this is based on the RankSquire pricing analysis and LeanOps cost audit, not the pricing page estimates.

Speaking of pricing pages: the average gap between what the pricing page shows and what your actual bill says is 2.5 to 4x. This comes from the LeanOps cost analysis across 47 production deployments. The culprits are egress fees, metadata storage overages, burst pricing, and the classic "that tier doesn't include replicas" surprise.

Based on the LeanOps data, here's the rule of thumb:

Below 60M queries per month: stick with hosted. The ops overhead of self-hosting isn't worth the savings.

Above 60M queries per month: self-hosting saves you 50 to 75%. At that query volume, you've already got the infra team and the monitoring in place. The marginal cost of running one more service is low compared to the managed pricing at that tier.

This tipping point shifts depending on your team. If you've got a platform team that already runs Kubernetes clusters, self-hosting a Qdrant cluster is a weekend project. If you're a team of five and your "infra" is clicking buttons in the AWS console, pay for managed and don't look back.

I'll be direct: most of you reading this should start with pgvector.

Here's my decision tree:

The "just use Postgres" advice is genuinely good advice for 80% of use cases. You already have Postgres. Your team already knows SQL. Your monitoring already covers it. Adding pgvector is a CREATE EXTENSION away.

Where Postgres falls short is at the extremes: if you need consistent sub-10ms latency at 50M+ vectors with concurrent writes, you'll want a purpose-built solution. But be honest with yourself about whether you're actually at that scale.

I've deployed pgvector, Qdrant, and Pinecone in production. Here's what I'd tell a friend:

Pinecone is the "nobody gets fired for buying IBM" choice. It works, it's reliable, and the DX is good. But you're paying a significant premium for the convenience, and the lock-in is real. There's no escape hatch if their pricing changes.

Qdrant is what I'd pick for a new project where performance matters. The Rust foundation makes a real difference in memory efficiency and tail latency. The API is well-designed. The open source community is active. And if you ever need to self-host, you can.

pgvector is what I'd recommend to anyone who asks "which vector database should I use?" as their first question. The answer is: you probably don't need a vector database. You need vector search, and Postgres can do that.

Weaviate is powerful but heavy. It's trying to be everything, and that means more knobs to turn and more things to go wrong. I'd pick it if I specifically needed its module ecosystem.

Chroma is great for local development and prototyping. I wouldn't run it in production for anything that matters.

Follow me on Youtube · LinkedIn · X · Instagram to stay updated.

See you in the next one!
Scortier, Signing Off!