Y

Here's what you need to understand to make a good call, and what questions to ask before you commit to anything.

What a vector database actually does

Normal databases store and retrieve exact values. You say "give me all users where country = Indonesia" and it does that. Fast. Reliable. Well-understood.

Vector databases do something different. They store numerical representations of meaning called embeddings and retrieve things based on similarity, not exact match. "Find me the ten documents most semantically similar to this user's question" is a fundamentally different operation from a SQL WHERE clause.

This matters most when you're building a [→ RAG system] where your AI answers questions by pulling relevant chunks from your company's documents before calling an LLM. The quality of that middle step is what determines whether your AI feature actually works. The vector database is what powers it.

The scale involved is non-trivial. A typical text embedding has 768 to 1,536 dimensions. Doing similarity search across millions of these by brute force is computationally brutal. Purpose-built vector databases use approximate nearest neighbor algorithms HNSW is the most common to make this fast. PostgreSQL can store vectors with the pgvector extension, but its default search is exact rather than approximate, which gets slow at scale.

Pinecone, Weaviate, pgvector what you're actually choosing between

Pinecone is a fully managed cloud service. No infrastructure to run. You push embeddings in, you query for similar results. That's the entire API. Teams that want to ship fast and skip infrastructure decisions tend to reach for it first.

The catch is cost. Pinecone's free tier is small. Once you're storing millions of vectors and running thousands of queries a day, the bill compounds quickly. At meaningful scale tens of millions of vectors you can be looking at $500–2,000 per month for the vector store alone. You also can't run it inside your own AWS account. Everything goes through Pinecone's infrastructure, which is fine until compliance or latency makes it not fine.

Weaviate is open source and can be self-hosted, though it also offers a managed cloud service. It's more opinionated about data structure than Pinecone it has a schema, understands objects, and stores metadata alongside vectors. That lets you combine semantic similarity with traditional filtering. "Find documents similar to this query, but only from the last 30 days and only from the Jakarta office" is where Weaviate's hybrid search model genuinely outperforms the alternatives.

Self-hosting is infrastructure work, though. Schema design, collection configuration, module setup. For a team that wants to move fast, it adds real surface area.

pgvector is a PostgreSQL extension. It adds a vector column type and similarity search operators to your existing Postgres database. Neon, Supabase, and most managed Postgres providers support it out of the box. No new infrastructure. No new vendor relationship. Transactions, backups, and row-level security all work because it's just Postgres.

The tradeoff: performance at extreme scale. pgvector's HNSW index has improved significantly over the last two years, but if you're doing semantic search across 50 million-plus vectors with high query throughput, a purpose-built system handles it more gracefully.

How to actually make the decision

Start here, not with benchmark posts from 2023.

Vector count matters most. Under a million vectors, pgvector is probably the right call. This covers most early-stage RAG implementations company wikis, support ticket archives, product documentation. Between one and ten million vectors, pgvector still works if query volume is moderate. Measure latency before assuming it's a problem. Beyond ten million, you have a concrete reason to evaluate Pinecone or Weaviate seriously.

Ops overhead has dollar value. If your team is already stretched on infrastructure, self-hosting Weaviate adds real work. Pinecone's managed experience removes that entirely. That matters even if it's hard to quantify on a spreadsheet.

Do you need hybrid search? If your AI feature needs to respect filters date ranges, user permissions, document categories hybrid search matters. Weaviate is built for it. pgvector handles it with SQL. Pinecone has metadata filtering, but it's more limited.

Your existing stack. If you're already running [→ Postgres as your primary database], starting with pgvector is low-risk. The migration story to a purpose-built system later is manageable embeddings are embeddings. You switch when production gives you a concrete reason to.

The part most founders get wrong

The vector database is not the expensive part of your AI stack.

The expensive part is embedding generation and LLM calls. Every document chunk you embed costs money. Every user query gets embedded before search runs. The LLM call after retrieval costs more still. Founders see a Pinecone bill and focus on that. The much larger line item, usually, is the OpenAI or Anthropic API costs. If you haven't instrumented those separately, you're guessing at your unit economics.

The second mistake: assuming retrieval is working because the output looks plausible. Your vector database can return the "closest" documents and still give your LLM the wrong context. This happens when chunking strategy is poor, when embeddings don't match the style of user queries, or when metadata filtering is too broad. The AI produces a confident-sounding answer that's wrong. Nobody catches it until a user does.

This is the kind of thing your team should be actively measuring from day one not discovering after a customer complaint. See how to approach that in [→ Building Reliable AI Features].

Real-world example

A logistics SaaS company they were building a support AI that could answer questions about shipment status, carrier policies, and delivery exceptions. They started with Pinecone because the demo took a weekend to build. Six months in, they had 800,000 document chunks indexed carrier policy documents, FAQ articles, and historical support tickets. Pinecone worked fine. Monthly cost: around $120.

The problem wasn't the database. It was retrieval accuracy. Queries like "why was my package delayed at the Surabaya hub" kept returning carrier policy documents instead of exception resolution guides. Similarity scores were high enough to clear threshold, but the LLM was getting the wrong context and producing plausible, wrong answers.

They spent two months tuning chunking strategy and adding metadata filters on document type before accuracy improved. That work would have been marginally easier with Weaviate's hybrid filtering model, but the bottleneck was never the database choice. It was the retrieval architecture. They're still on Pinecone.

FAQ

Q: Can I just use PostgreSQL instead of a dedicated vector database? A: Yes, with the pgvector extension. For most early-stage products under a million vectors with moderate query volume pgvector on your existing Postgres setup is a reasonable default. Add a dedicated vector database when you have a concrete performance reason, not before.

Q: What's the difference between an embedding and a vector? A: In practice, the same thing. An embedding is a list of numbers that represents the meaning of some content text, image, or code. When people say "vector database," they mean a system optimised for storing and searching these numerical arrays efficiently.

Q: How much does a vector database cost for a startup? A: pgvector costs nothing extra if you're already on Postgres. Pinecone's free tier handles small projects. At production scale millions of vectors, thousands of daily queries budget $200–$1,000 per month for a managed solution. Your LLM API costs will likely exceed that.

Q: What is hybrid search and do I need it? A: Hybrid search combines semantic similarity with traditional filtering find documents similar to this query, but only from the last 90 days, only from Category X. If your AI feature needs to respect date ranges, user permissions, or document types, you need hybrid search. pgvector handles it with SQL. Weaviate is purpose-built for it.

Q: When should I switch from pgvector to Pinecone or Weaviate? A: When production data gives you a concrete reason. Semantic search latency is spiking. Postgres CPU is saturated under vector workload. Hybrid search SQL is getting unmaintainable. Don't switch because you read a benchmark switch because you have numbers showing you need to.

Pick the simplest option that fits your current scale, measure retrieval quality from day one, and revisit the database decision when production tells you to. The architecture choices that matter most how you chunk documents, how you evaluate retrieval, how you handle failure have nothing to do with which vendor you pick. If you're not sure whether your current AI setup is built to hold up under load, that's worth a conversation before it becomes a 3am incident.