Vector Databases: Pinecone, Chroma, Qdrant and pgvector

The First Time I Heard "Vector Database" I Googled It Four Times

I'm not going to pretend I understood vector databases the first time someone mentioned them. I was building a basic RAG pipeline, someone told me I needed a "vector store," and I spent an afternoon reading docs that assumed I already knew what I was doing. Fun times.

Here's what I eventually figured out: vector databases aren't magic, they're not always necessary, and the choice between them is actually pretty logical once you understand what problem they're solving. So let me walk you through it the way I wish someone had walked me through it.

What a Vector Database Actually Does

When you convert text into embeddings (those big arrays of numbers that represent meaning), you end up with something like a 1536-dimensional vector for each chunk of text. A regular database can store those — but it's terrible at searching them.

Why? Because searching vectors isn't like looking up a row by ID or filtering by date. You want to find the nearest neighbors — the vectors that are most mathematically similar to your query vector. That's called ANN search (Approximate Nearest Neighbor), and regular SQL indexes aren't built for it.

Vector databases are purpose-built for exactly this. They use special index structures — things like HNSW (Hierarchical Navigable Small World) graphs — that let you search millions of high-dimensional vectors in milliseconds. That's the core job.

The Four Options You'll Actually Encounter

Let's walk through the real players. I'll keep this practical — what each one is, who it's for, and what it actually costs you to get started.

Pinecone is the fully managed, cloud-hosted option. You don't install anything, you don't manage infrastructure, you just create an index and start upserting vectors via API. It's the easiest starting point if you want to skip ops entirely. The free tier is generous enough for prototyping, but costs climb once you're storing millions of vectors. This is what I'd recommend if you're building something you want live quickly and don't want to think about servers.

Chroma is the local-first, open-source option. It runs in-memory or persists to disk, installs with a single pip install chromadb, and you're querying in five minutes. I used Chroma for almost every RAG prototype I built before moving anything to production. It's excellent for development, local tools, and projects where you don't need scale. The catch: it's not really designed for production deployments serving millions of requests.

Qdrant is the open-source option that scales. You can run it locally via Docker for development and deploy it to a cloud cluster for production. It supports HNSW indexing, payload filtering, and has a clean API. If you want the control of self-hosting without sacrificing production-grade performance, Qdrant is where I'd look. There's also a managed cloud option if you want hosted Qdrant without the Pinecone pricing.

pgvector is a PostgreSQL extension that adds a vector type and ANN search to your existing Postgres database. If you're already running Postgres — which most web apps are — you can add pgvector with two lines and start storing vectors in a regular table column. No new service, no new bill, no new thing to learn. It's not as fast as dedicated vector databases at massive scale, but for most projects, you'll never hit that ceiling.

When You Actually Need a Dedicated Vector Database

Here's the honest answer: less often than vendors want you to think. But there are real cases where dedicated vector databases earn their place.

You want a dedicated vector database when you're storing millions of vectors and need sub-100ms query times at scale. When you need advanced features like multi-vector search, sparse-dense hybrid search, or filtering on complex metadata while searching. When your team doesn't already run Postgres and you don't want to add it just for vectors. And when you're building something where vector search is the core product, not an add-on feature.

Pinecone is the right call when you want fully managed, zero ops, and you can absorb the cost. Qdrant is the right call when you want dedicated performance but prefer self-hosting or want to avoid Pinecone's pricing ceiling.

When Postgres Is Plenty

Honestly? Most side projects, internal tools, and even early-stage products are fine with pgvector. I've seen people spin up Pinecone for a tool that stores 2,000 documents. That's like renting a warehouse for a filing cabinet.

Use pgvector when: you're already on Postgres and don't want another service to manage, your vector count is under a few hundred thousand (maybe even a million with good indexing), you want to filter by metadata using SQL joins (which is actually a superpower — combining vector search with relational data is much easier in SQL), or you're building something and want to validate the idea before adding infrastructure.

A Simple Decision Tree

When someone asks me which to use, I walk through it like this:

Is it a prototype or local dev tool? → Use Chroma. Done.

Are you already running Postgres in production? → Add pgvector first. See if it's fast enough. It probably is.

Do you need scale beyond ~1M vectors, or features like hybrid search? → Self-hosted Qdrant (Docker or managed) is my pick.

Do you want zero ops and are okay with the pricing? → Pinecone.

The thing that tripped me up early was thinking I needed to make the "right" choice upfront. You don't. Swap Chroma for pgvector in a few hours. Swap pgvector for Qdrant in a day. These aren't irreversible decisions — they're just storage backends, and abstracting them behind a thin retrieval function in your code makes it even easier to switch.

The Bottom Line

Vector databases solve a specific problem: fast approximate nearest-neighbor search over high-dimensional embeddings at scale. If you don't have scale, you don't need a dedicated one. Postgres with pgvector is legitimately excellent for most real-world use cases, and Chroma gets you moving in five minutes during development.

Pick the simplest thing that works for where you are right now, and build in a way that lets you swap it later. That's not a cop-out answer — that's actually the experienced move. The engineers who jump straight to a managed vector database cluster for their first RAG experiment are the ones who end up paying $50/month to search 800 documents.

Start simple. Scale when the scale is real.