Vector Databases

pgvector, Pinecone, Weaviate.

Overview

Vector databases store and query high-dimensional embeddings for RAG, semantic search, and recommendation. The choice is between pgvector (Postgres extension), Pinecone (managed service), Weaviate (open-source self-hosted), and a growing list of others. The decision criteria are operational profile (managed vs self-hosted), scale ceiling (millions vs billions of vectors), and whether the team already operates Postgres. Most teams should start with pgvector and only migrate when they hit a real ceiling.

• pgvector, Pinecone, Weaviate. Three different operational profiles; the choice matches team operational maturity and scale.
• pgvector: Postgres extension. Adds vector support to existing Postgres; right for teams already running Postgres at the scale that fits.
• Pinecone: managed service. No cluster ops; right for small teams or workloads that exceed pgvector’s ceiling.
• Weaviate: open-source plus HNSW indexing. Self-hosted with rich features (hybrid search, multi-modal); HNSW (Hierarchical Navigable Small World) is the dominant approximate-nearest-neighbor algorithm.

The approach

The practical approach is pgvector by default for teams already running Postgres (the vector workload reuses existing infrastructure), managed (Pinecone) for very large workloads or small teams without database operational capacity, self-hosted Weaviate when control or feature breadth matters, evaluation with real production-like workloads (synthetic benchmarks lie), and per-workload rationale documented committed to the infrastructure repo.

• pgvector default. Most teams already have Postgres; the operational savings of reusing existing infra are significant.
• Managed for scale. Pinecone for very large workloads or small teams; the managed offering removes cluster operations from the team’s plate.
• Self-hosted Weaviate. When control matters or feature breadth (hybrid search, multi-modal) justifies the operational complexity.
• Evaluate with real data plus documented choice. Benchmark with production-like queries; per-workload rationale committed to the infrastructure repo.

Why this compounds

Vector database choice compounds across the AI surface. Each correct selection avoids the painful migration when the workload outgrows the wrong choice; each documented rationale survives team turnover; the team builds vocabulary for AI-infrastructure tradeoffs that pays off on every new feature.

• Operational fit. Right database for the workload; the team operates at the complexity the workload actually requires.
• Cost efficiency. pgvector reuses existing Postgres infrastructure; the per-vector cost stays low for teams already running Postgres.
• Reduced switching cost. Right choice up front avoids the migration when the workload grows; the wrong choice is locked in by foreign keys and integration code.
• Institutional knowledge. Each vector workload teaches embedding patterns; the team learns where vector databases shine and where they struggle.

Vector database choice is an AI-infrastructure discipline that pays off across years. Nova AI Ops integrates with vector telemetry, surfaces vector patterns, and supports the team’s AI infrastructure discipline.