Vector Databases for Full Stack Developers: When You Need One and When You Absolutely Don't

The moment you add an AI feature to your application, someone on the team suggests a vector database. The suggestion sounds right. Vector databases and AI features seem to belong together the way React and TypeScript do — a natural pairing.

So you spin up a Pinecone instance, integrate it into your backend, spend a week building the embedding pipeline, and ship the feature. Then you realise your application has 8,000 users with an average of 200 stored items each. Your PostgreSQL instance with a basic full-text search index would have answered 90% of those queries faster, cheaper, and with zero additional infrastructure.

This is the vector database adoption pattern that plays out constantly in production. Not because developers aren't smart — because the use case guidance available almost everywhere comes from vendors selling vector databases, not from practitioners who've built the wrong solution and had to rebuild.

This article gives you the decision framework that comes from building real systems.

The Decision You're Actually Making

When you add a vector database to a project, you're making several implicit architectural decisions simultaneously:

• The search problem you're solving is semantic (meaning-based), not lexical (keyword-based)
• The query volume and dataset size justify the infrastructure overhead
• The latency added by the embedding-generation-plus-retrieval pipeline is acceptable
• The operational complexity is worth the capability it unlocks

Each of these assumptions can be wrong for a specific application.

The question that should come first:

What kind of search problem am I actually solving?

There are only two fundamental search problems:

Lexical search: Finding documents that contain specific words or phrases. "Show me products with 'wireless' in the name" or "find all users where email contains '@example.com'". This is exact and near-exact matching. Every relational database does it well with proper indexing.

Semantic search: Finding documents that mean something similar to a query, regardless of exact wording. "Find products similar to what this user has been browsing" or "find documentation that answers this question even if different terminology was used." This requires understanding meaning, not matching characters. This is where vector databases become relevant.

If your actual problem is lexical, you do not need a vector database.

When to Use PostgreSQL Full-Text Search Instead

PostgreSQL's built-in full-text search with tsvector and tsquery handles most search problems that developers initially reach for vector databases to solve:

-- Add full-text search to a products table
ALTER TABLE products ADD COLUMN search_vector tsvector;

UPDATE products SET search_vector = 
  to_tsvector('english', name || ' ' || COALESCE(description, ''));

CREATE INDEX products_search_idx ON products USING GIN(search_vector);

-- Query
SELECT * FROM products 
WHERE search_vector @@ to_tsquery('english', 'wireless & keyboard')
ORDER BY ts_rank(search_vector, to_tsquery('english', 'wireless & keyboard')) DESC
LIMIT 20;

This handles: product search, documentation search, article search, user search, most "find relevant content" use cases in applications under ~1 million records.

Performance: sub-10ms for most queries on properly indexed datasets up to 10 million records. No additional infrastructure. No embedding pipeline. No API costs.

The pgvector Extension: The Middle Ground

If you genuinely need semantic search but your dataset is under ~500,000 records, the pgvector PostgreSQL extension is almost always the right answer before reaching for a dedicated vector database.

-- Enable pgvector
CREATE EXTENSION IF NOT EXISTS vector;

-- Add embedding column
ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- Create index for approximate nearest neighbor search
CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

-- Store embeddings (done from application code)
UPDATE documents SET embedding = $1 WHERE id = $2;

-- Semantic search
SELECT id, title, 1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 10;

pgvector keeps your data in PostgreSQL alongside your relational data. You don't need to sync data between two databases, manage two connection pools, or deal with the operational overhead of a separate vector store.

Use pgvector when:

• Dataset under ~500,000 vectors
• Query volume under ~500 QPS for vector search
• You want to keep operational complexity low
• You need to join vector search results with relational data

When a Dedicated Vector Database Is Justified

A dedicated vector database (Pinecone, Weaviate, Qdrant, Chroma) becomes the correct choice when:

Scale genuinely requires it. Above ~1 million vectors or above ~1,000 QPS for vector search, purpose-built vector databases have significant performance advantages over pgvector. Their indexing algorithms (HNSW, IVF) are optimised specifically for approximate nearest neighbor search at scale.

You need advanced vector operations. Hybrid search (combining semantic and keyword search), metadata filtering at scale, multi-tenancy with isolated namespaces, real-time index updates at high write volumes — dedicated vector databases handle these better.

The embedding pipeline is a core product function. If vector search is central to your product value (recommendation engine, semantic document search, RAG over large knowledge bases), the specialised tooling justifies the operational overhead.

RAG: When Vector Databases Are Actually Essential

Retrieval-Augmented Generation (RAG) is the pattern where you retrieve relevant context from a knowledge base and include it in your LLM prompt. This is one of the primary legitimate use cases for vector databases.

async function generateWithContext(userQuery, vectorDB) {
  // 1. Embed the user's query
  const queryEmbedding = await embed(userQuery);
  
  // 2. Retrieve semantically similar documents
  const relevantDocs = await vectorDB.search({
    vector: queryEmbedding,
    topK: 5,
    minScore: 0.75,
  });
  
  // 3. Include retrieved context in the LLM prompt
  const context = relevantDocs.map(d => d.content).join('\n\n');
  
  const response = await openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [
      {
        role: 'system',
        content: `Answer the user's question based on the following context:\n\n${context}`
      },
      { role: 'user', content: userQuery }
    ],
  });
  
  return response.choices[0].message.content;
}

RAG over a large knowledge base (documentation, support articles, legal documents, product catalogs) is a genuine semantic search problem. If the knowledge base has more than ~10,000 documents, a vector database — or at minimum pgvector — is the right tool.

The Decision Framework

Dataset Size	Query Volume	Use Case	Recommendation
Any	Any	Keyword/exact search	PostgreSQL full-text
< 500k vectors	< 500 QPS	Semantic search	pgvector
500k–5M vectors	500–2,000 QPS	Semantic search	Qdrant or pgvector
> 5M vectors	> 2,000 QPS	Semantic search	Pinecone or Weaviate
Any	Any	RAG over docs	pgvector (small) / dedicated (large)

The Operational Reality

Adding a dedicated vector database means:

• A new service to deploy, monitor, and maintain
• A new connection pool to manage
• Data synchronisation between your primary database and the vector store
• Embedding updates when source data changes
• A new cost line (Pinecone starts at ~$70/month for production tier)
• A new failure mode (vector DB outage affects search features)

pgvector means none of the above. It's an extension to the database you're already running.

The question is never "should I use a vector database?" The question is "does my specific problem actually require one, or am I adding infrastructure for a problem that doesn't exist in my dataset?"

Most applications that add vector databases don't need them. Most applications that skip vector databases and use pgvector make the right call. The exceptions — RAG over large knowledge bases, recommendation at scale, semantic search over millions of records — are real and important. They're just less common than the adoption pattern suggests.