How We Pick a Vector Database for Early-Stage AI Products

Every founder building an AI product runs into the same fork in the road within the first two weeks: where do the embeddings live? The wrong choice costs you a rebuild. The right one is boring and gets out of the way.

At Augere Labs we ship RAG-heavy products for a living — support copilots, internal search, agent workflows. We've picked, migrated off, and defended most of the popular vector stores in the last two years. This is the honest version of the conversation we have with founders on day one.

Short answer:

• Under 1M vectors and already on Postgres? Use pgvector. Stop reading.
• Multi-tenant SaaS, want zero infra to run? Pinecone serverless.
• Self-hosted, want the fastest recall/latency for the price? Qdrant.
• Need built-in hybrid search + modules? Weaviate.

What "vector database" actually means in 2026

A vector database stores embeddings — numeric fingerprints of text, images, or audio — and returns the nearest neighbours to a query embedding. That's it. The interesting differences aren't the algorithm (they all use HNSW or a variant); they're what wraps around it: filtering, metadata, hybrid search, multi-tenancy, and cost.

Two years ago the choice mattered less because most products only did one thing: "find me the top 5 chunks that look like this question." Today a typical retrieval query filters by tenant, by document type, by date, by user permission, and blends keyword and vector scores. That's where the databases separate.

The four options worth taking seriously

pgvector (Postgres extension)

An extension that adds a vector column type to Postgres. Runs anywhere Postgres runs — Supabase, Neon, RDS, your laptop.

Where it wins: your data already lives in Postgres. Joins with your documents, users, tenants tables happen inside the same query. No two-write problem. No sync jobs. RLS policies extend to your vectors for free.

Where it hurts: HNSW index build is single-threaded and gets slow past ~5M rows. Recall tuning (ef_search) takes a bit of homework. You're on the hook for vacuum and index maintenance.

Real numbers: on a Supabase Pro instance we've comfortably run 800K chunks (1536-dim OpenAI embeddings) with p95 query latency around 45–70ms including a tenant filter. That's plenty for most B2B SaaS.

Pinecone

A fully managed vector database. You never see a server. Serverless tier bills per read/write plus storage.

Where it wins: zero operational load, elastic scale, namespaces for multi-tenancy, fast cold starts on serverless. If your team is one founder and a designer, it saves you weekends.

Where it hurts: your embeddings live somewhere else than your app data. Every retrieval is two hops — one to Postgres for metadata, one to Pinecone for vectors. Costs scale with query volume, and a chatty agent can surprise you at month-end.

When we pick it: multi-tenant SaaS where a customer might have 50M chunks tomorrow, and we don't want to be paged when they do.

Qdrant

Open-source, Rust-based, and — in our benchmarks — the fastest of the self-hosted options at similar recall. Also available as Qdrant Cloud.

Where it wins: excellent filtering performance (payload indexes are first-class), quantization support that drops memory 4×, and a genuinely nice REST/gRPC API. Hybrid search via BM25 payloads works well.

Where it hurts: smaller community than Pinecone or pgvector, and if you self-host you need to think about backups, snapshots, and HA yourself.

Weaviate

Open-source, Go-based, with a modular architecture (built-in reranker, generative, and multi-modal modules).

Where it wins: hybrid search (BM25 + vector) is native and well-tuned. If you want a database that already ships with reranking and cross-encoder support, it's the least assembly required.

Where it hurts: heavier resource footprint than Qdrant, and the schema/class model has a learning curve if your team is used to plain SQL.

What we actually check before picking

In projects like these, the tech shortlist is the easy part. The questions we ask the founder are what decide it:

• How many vectors in 12 months? Under 1M, pgvector. Over 20M, managed.
• How many tenants? Under 50, a shared collection with a tenant filter is fine. Over that, namespaces matter.
• Are your embeddings the source of truth or a cache? If they're derived from documents that change often, put them next to the documents (pgvector).
• What's your team's on-call story? One dev, no ops → managed. Real backend team → self-hosted is cheaper.
• Do you need hybrid search on day one? Yes → Weaviate. Maybe → Qdrant. Later → pgvector with a tsvector column.

A common mistake we see

Founders read a benchmark blog post, pick the fastest option on paper, and start with 200 documents. Six months later they have 50K documents, three tenants, RLS requirements, and they're maintaining a nightly sync job from Postgres to their vector store because "we needed a specialized DB." They didn't. Their bottleneck was never the vector database — it was chunking strategy and reranking.

A pattern we see too often: teams pay $400/mo for a hosted vector DB to store what would have been a $0 ALTER TABLE ADD COLUMN embedding vector(1536) on their existing Supabase project.

Cost, honestly

Rough monthly cost for 1M embeddings (1536-dim), moderate query volume:

• pgvector on Supabase Pro: $25 base — vectors ride along.
• Pinecone serverless: $50–$120 depending on QPS.
• Qdrant Cloud: $50–$90 for a small managed cluster.
• Weaviate Cloud: $85–$150 similar tier.
• Self-hosted Qdrant on a $20 Hetzner box: $20 + your weekend.

These are 2026 numbers pulled from live projects. They shift, but the ranking rarely does.

How we'd build it from scratch today

For 90% of the AI products we build at Augere Labs, the stack looks like this:

1. Supabase Postgres with pgvector for embeddings and metadata in the same rows.
2. Chunking pipeline that runs on a background queue (usually Trigger.dev or a Cloudflare Queue).
3. An ivfflat or hnsw index tuned once, then measured monthly.
4. A reranker (Cohere or a small cross-encoder) sitting between retrieval and the LLM. This matters more than the database choice — a bad DB with a good reranker beats the reverse every time.

We only reach for Pinecone or Qdrant when we cross ~10M chunks or when a customer explicitly needs sub-30ms p99 at high QPS. Both are real cases; neither is common in the first year of a startup.

Migration is easier than picking wrong

A quiet truth of vector databases: migrating between them is a two-day job, not a two-month one. The embeddings themselves are portable — same float arrays, same dimensions. You re-upload them and rebuild the index. If you pick pgvector and outgrow it in year two, you'll switch in a sprint. Optimize for the decision that gets you to launch, not the one that survives an imagined Series B.

Trade-offs no one tells you

• HNSW parameters lie in benchmarks. Default settings favour throughput over recall. Always tune with your own data.
• Filtering kills performance more than dimension count does. A strict WHERE tenant_id = ? can halve QPS on any of these systems if the index isn't set up for it.
• Embedding model choice matters more than the DB. Switching from OpenAI text-embedding-3-small to a fine-tuned domain model often improves retrieval more than any database swap.

How this fits with the rest of your stack

Your vector database sits between three other decisions — none of them independent:

• Embedding provider (OpenAI, Voyage, Cohere, or an open model). Determines dimension and cost per million tokens.
• Retrieval strategy (pure vector, hybrid, or graph-augmented). Determines what your DB needs to support.
• LLM (Claude, GPT-4o, Llama). Determines how forgiving your retrieval can be. See our LLM comparison for the current landscape.

Change any of them and the "right" vector DB can change too. Pick embeddings first, LLM second, DB third.

Frequently asked questions

Is pgvector production-ready?

Yes. It's used in production at scale by teams handling tens of millions of vectors. The limits are operational (index build time, single-node scale), not correctness.

Do I need a vector database at all?

If you have fewer than 10K documents and Postgres, you don't. A vector column with an HNSW index or even a brute-force scan is fine. Add complexity only when a metric forces you to.

What about ChromaDB or LanceDB?

Both are excellent for local development and prototypes. We rarely put them in production because their operational stories are less mature than the four above. Great for a Jupyter notebook, less great for a customer paging you at 2am.

Should I use OpenAI's file search or Assistants API instead?

If your product is a thin wrapper around ChatGPT for internal docs, yes — it's the fastest path to a demo. For anything you want to own, control cost on, or fine-tune retrieval for, you'll want your own vector store within six months.

Vector DB vs graph DB for RAG?

Not either-or. Graph DBs shine when relationships matter (compliance, org charts, medical). We usually combine — a vector store for semantic recall, a graph or SQL join for structural context.

Where to go next

If you're at the picking-a-stack stage, read our RAG vs fine-tuning guide next — the vector DB choice only matters if RAG is the right pattern in the first place. If you already know what you're building and want it shipped, we do exactly this at Augere Labs: senior engineers, no juniors, MVPs in 30 days.

Book a 30-minute call and we'll sketch the stack live — no slide deck, no upsell.