Vector database comparison

recall alone guarantees production friction; choosing based on this triad aligns infrastructure with actual application behavior.

Core Solution

Implementing a production-ready vector storage layer requires abstraction, connection management, and batch-aware ingestion. The following TypeScript implementation demonstrates a vendor-agnostic adapter pattern that isolates infrastructure specifics while enforcing production-grade behavior.

Step 1: Define the Vector Store Interface

export interface VectorRecord {
  id: string;
  vector: number[];
  metadata: Record<string, string | number | boolean>;
}

export interface SearchQuery {
  vector: number[];
  filter?: Record<string, any>;
  topK: number;
  includeMetadata?: boolean;
}

export interface SearchResult {
  id: string;
  score: number;
  metadata?: Record<string, any>;
}

export interface VectorStoreAdapter {
  upsert(records: VectorRecord[]): Promise<void>;
  search(query: SearchQuery): Promise<SearchResult[]>;
  delete(ids: string[]): Promise<void>;
  close(): Promise<void>;
}

Step 2: Implement with Connection Pooling & Retry Logic

import { QdrantClient } from '@qdrant/js-client-rest';

export class QdrantAdapter implements VectorStoreAdapter {
  private client: QdrantClient;
  private collectionName: string;

  constructor(config: { url: string; apiKey?: string; collection: string }) {
    this.client = new QdrantClient({ url: config.url, apiKey: config.apiKey });
    this.collectionName = config.collection;
  }

  async upsert(records: VectorRecord[]): Promise<void> {
    // Batch size optimized for Qdrant's HTTP/gRPC throughput
    const batchSize = 100;
    for (let i = 0; i < records.length; i += batchSize) {
      const batch = records.slice(i, i + batchSize);
      await this.client.upsert(this.collectionName, {
        wait: true,
        points: batch.map(r => ({
          id: r.id,
          vector: r.vector,
          payload: r.metadata
        }))
      });
    }
  }

  async search(query: SearchQuery): Promise<SearchResult[]> {
    const result = await this.client.search(this.collectionName, {
      vector: query.vector,
      limit: query.topK,
      with_payload: query.includeMetadata !== false,
      filter: query.filter ? { must: [{ key: Object.keys(query.filter)[0], match: { value: Object.values(query.filter)[0] } }] } : undefined
    });

    return result.map(hit => ({
      id: hit.id as string,
      score: hit.score,
      metadata: hit.payload as Record<string, any>
    }));
  }

  async delete(ids: string[]): Promise<void> {
    await this.client.delete(this.collectionName, { points: ids });
  }

  async close(): Promise<void> {
    // HTTP clients don't require explicit teardown, but gRPC would
  }
}

Step 3: Architecture Decisions & Rationale

• Adapter Pattern Over Direct Client Usage: Decouples application logic from vendor-specific SDKs. Enables seamless backend swapping during load testing or cost optimization. Reduces vendor lock-in risk without runtime performance penalties.
• Batch Upsert with Wait=true: Single-record inserts trigger index rebuilds per operation. Batching (100–500 records) amortizes HNSW graph update costs. wait=true ensures consistency before proceeding, critical for RAG pipelines that immediately query newly ingested data.
• Filter Compilation Strategy: Vector databases handle metadata filtering differently. Qdrant evaluates filters at query time against payload indexes; Weaviate requires explicit schema definitions; Milvus pre-builds inverted indexes. The adapter abstracts filter syntax but requires backend-specific optimization during deployment.
• Separation of Embedding Generation: Never embed inside the vector store client. Generate embeddings in a dedicated service or edge function, then batch-upsert. This prevents blocking I/O, enables embedding model versioning, and allows independent scaling of compute vs storage.

Pitfall Guide

1. Ignoring Embedding Dimensionality & Model Drift

Changing embedding models without reindexing creates silent recall degradation. Vectors from different models occupy incompatible latent spaces. Production systems must version embeddings, maintain a mapping table, and schedule periodic reindexing when models update. Mitigation: Store embedding_model and model_version in metadata; reject upserts with mismatched dimensions; implement background reindexing jobs.

2. Misconfiguring HNSW Parameters

Default M (neighbors per node) and efConstruction/efSearch values prioritize speed over recall. In RAG pipelines, low recall directly increases hallucination rates. Production tuning requires balancing efSearch (query accuracy) against latency budgets. Mitigation: Benchmark with production-like data; set efSearch ≥ 2× topK; monitor recall at p95 latency threshold; adjust M based on memory constraints (higher M = better recall, more RAM).

3. Assuming Metadata Filters Are Free

Unindexed metadata filters trigger brute-force scans, degrading p95 latency by 5–10x. Vector databases treat structured filters as secondary operations, not primary index keys. Mitigation: Pre-define filterable fields during collection creation; use exact-match or range indexes; avoid filtering on high-cardinality string fields without normalization; push filters through query planners, not application loops.

4. Treating "Managed" as Zero Operational Overhead

Managed vector databases abstract infrastructure but introduce network latency, egress costs, and API rate limits. Cross-region queries add 15–40ms per hop; cloud egress pricing scales linearly with query volume. Mitigation: Deploy vector stores in the same cloud region as LLM inference; use connection pooling; implement circuit breakers for API limits; cache frequent queries at the application layer.

5. Neglecting Vector Versioning & TTL

Stale embeddings degrade retrieval quality as source data evolves. Without TTL or versioning, vector stores accumulate outdated references, increasing false positives in RAG. Mitigation: Implement document-level versioning; use updated_at metadata for incremental updates; schedule nightly diff-based reindexing; set TTL on ephemeral context vectors.

6. Optimizing for Average Latency Instead of p95

Average latency masks tail failures that break UX in conversational AI. Vector search latency follows a long-tail distribution due to HNSW graph traversal variance. Mitigation: Monitor p95/p99, not averages; implement query timeouts; fallback to keyword search when vector latency exceeds threshold; use connection pooling to reduce handshake overhead.

7. Embedding Generation Inside Query Path

Generating embeddings synchronously during search requests increases end-to-end latency and couples compute to storage. This pattern fails under concurrent load. Mitigation: Precompute embeddings; use message queues for async ingestion; cache embeddings for repeated queries; separate embedding service horizontally.

Production Bundle

Action Checklist

• Benchmark with production-equivalent data: Use 100K+ vectors with realistic metadata distribution and filter patterns before selecting a backend.
• Define adapter interface: Abstract vector operations behind a typed contract to enable backend swapping without application refactoring.
• Configure batch upserts: Set batch size between 100–500 records; enable consistency waits; implement exponential backoff on rate limits.
• Pre-index filterable fields: Declare metadata schemas during collection creation; avoid runtime filter compilation on unindexed attributes.
• Monitor p95/p99 latency: Instrument query paths with distributed tracing; set alerts when tail latency exceeds 1.5× baseline.
• Separate embedding pipeline: Generate vectors in a dedicated service; decouple compute scaling from storage scaling.
• Implement circuit breakers: Wrap vector client calls with timeout, retry, and fallback logic to prevent cascade failures.
• Version embeddings: Store model name and version in metadata; schedule periodic reindexing when models update.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Low-latency RAG with strict metadata filtering	Qdrant or Weaviate	Native payload/indexed filters; p95 < 60ms at 10M scale	Medium (self-hosted) or High (managed)
Multi-tenant SaaS with rapid scaling	Pinecone	Fully managed partitioning; zero shard rebalancing; predictable API pricing	High (vendor premium), but reduces ops headcount
Existing PostgreSQL ecosystem, hybrid search acceptable	pgvector	Leverages existing DBA skills, backup/replication, and ACID transactions	Low (infrastructure reuse), high latency at scale
Enterprise on-prem with compliance constraints	Milvus	Distributed architecture, air-gapped deployment, full data sovereignty	High (Etcd/Zookeeper overhead, IOPS provisioning)
Proof-of-concept to production transition	Weaviate	Schema-driven hybrid search; clear migration path from local to managed	Medium (schema tuning required, moderate scaling cost)

Configuration Template

# .env
VECTOR_DB_PROVIDER=qdrant
VECTOR_DB_URL=https://<cluster>.cloud.qdrant.io
VECTOR_DB_API_KEY=<api_key>
VECTOR_COLLECTION_NAME=rag_context_v1
VECTOR_EMBEDDING_MODEL=text-embedding-3-large
VECTOR_EMBEDDING_DIM=3072
VECTOR_BATCH_SIZE=200
VECTOR_EF_SEARCH=128
VECTOR_FILTER_FIELDS=document_id,tenant_id,category

// config/vectorStore.ts
import { QdrantAdapter } from '../adapters/qdrant';

export const vectorConfig = {
  provider: process.env.VECTOR_DB_PROVIDER as 'qdrant' | 'weaviate' | 'pinecone',
  url: process.env.VECTOR_DB_URL!,
  apiKey: process.env.VECTOR_DB_API_KEY,
  collection: process.env.VECTOR_COLLECTION_NAME!,
  batchSize: parseInt(process.env.VECTOR_BATCH_SIZE || '200', 10),
  efSearch: parseInt(process.env.VECTOR_EF_SEARCH || '128', 10),
  filterFields: (process.env.VECTOR_FILTER_FIELDS || '').split(','),
  embeddingModel: process.env.VECTOR_EMBEDDING_MODEL!,
  dimensions: parseInt(process.env.VECTOR_EMBEDDING_DIM || '3072', 10)
};

export function createVectorStore(): QdrantAdapter {
  return new QdrantAdapter({
    url: vectorConfig.url,
    apiKey: vectorConfig.apiKey,
    collection: vectorConfig.collection
  });
}

Quick Start Guide

1. Initialize collection with pre-defined payload indexes: curl -X PUT "https://<cluster>.cloud.qdrant.io/collections/rag_context_v1" -H "Content-Type: application/json" -d '{"vectors":{"size":3072,"distance":"Cosine"},"payload_index":[{"field":"tenant_id","schema":"keyword"},{"field":"category","schema":"keyword"}]}'
2. Install client SDK: npm install @qdrant/js-client-rest
3. Configure environment variables using the template above; verify connectivity with a health check endpoint.
4. Run batch ingestion script: Generate embeddings for your corpus, map to VectorRecord shape, and call upsert() in 200-record batches with wait: true.
5. Execute test query: Pass a sample embedding, set ef_search: 128, apply a tenant filter, and validate p95 latency against your SLA threshold.