Good QuestionChajgo itneun Deo naeun vector databases Haegyeol?

A vector database is a storage and retrieval system specialized for high-dimensional embedding vectors — the numerical representations produced by models like OpenAI text-embedding-3-large, Voyage-3-large, or Cohere embed-english-v4. Instead of searching by exact keyword match, you search by semantic similarity: "find me the 50 product reviews most like this query," "retrieve the 10 internal documents closest in meaning to this customer ticket," "surface images that look like this one." Under the hood, vector DBs index those embeddings using approximate nearest-neighbor (ANN) algorithms such as HNSW, IVF-PQ, ScaNN, and DiskANN to deliver single-digit-millisecond lookups across hundreds of millions of items.

The 2026 vector DB landscape matters because retrieval-augmented generation has become the default architecture for production AI: you cannot fit your entire knowledge base into even a 2M-token context window, so you embed your data, store the vectors, and retrieve the top-K relevant chunks at query time. Beyond RAG, vector DBs power semantic search, deduplication, recommendation, anomaly detection, code search (think Cursor and Copilot), and any system that needs embeddings at scale.

The shape of the market in 2026: managed services (Pinecone, Weaviate Cloud, Qdrant Cloud) dominate new RAG builds; pgvector eats the under-10M-vector segment for Postgres shops; Milvus and Qdrant own self-hosted at hyperscale; and open-source LanceDB and Chroma rule local development. Swfte Studio integrates with all of them so you can swap stores without rewriting your retrieval layer.

Vector search is dominated by four families of approximate nearest-neighbor (ANN) algorithms, each with sharply different trade-offs once your corpus crosses 1M items. HNSW (Hierarchical Navigable Small World) builds a multi-layer proximity graph where queries greedily walk from a coarse top layer down to a dense base layer; it dominates managed vendors (Pinecone, Weaviate, Qdrant, pgvector) because it delivers 0.95-0.99 recall at sub-10ms latency on million-scale indexes. The cost is RAM: a 768-dim float32 HNSW graph eats roughly 4-6KB per vector, so 100M vectors needs 400-600GB of memory. IVF-PQ (Inverted File with Product Quantization) clusters vectors into Voronoi cells and compresses each into 8-32 bytes via product quantization. It cuts memory 16-64x at the price of 1-3% recall and slightly higher latency — the workhorse for 100M+ vector workloads in Milvus, Faiss, and pgvectorscale. DiskANN (Microsoft) and its successor FreshDiskANN hold most of the graph on NVMe SSD, fetching only the visited nodes; this delivers 50-100M vectors per node at 5-30ms p99 with 90%+ less RAM than HNSW. ScaNN (Google) uses anisotropic vector quantization optimized for inner-product loss and is the foundation of Vertex AI Vector Search and most internal Google retrieval.

The recall vs latency trade-off is the daily knob: turning efSearch in HNSW from 64 to 256 lifts recall@10 from 0.94 to 0.99 but doubles tail latency. Heavy metadata pre-filters (e.g. tenant_id IN (...) AND lang = 'en') punish HNSW more than IVF-PQ because they break graph locality. What changes at each scale tier: at 1M vectors, almost any algorithm on a single node hits sub-10ms p99 — pick whatever is operationally simplest. At 10M vectors, RAM cost forces a real choice: HNSW if latency-critical, IVF-PQ if cost-sensitive, and you start caring about index build time (HNSW rebuilds at 10M can take 30+ minutes). At 100M vectors, sharding across 4-8 nodes becomes mandatory, DiskANN or IVF-PQ replaces in-memory HNSW for cost reasons, and you need real query routing. At 1B vectors, you are operating a small distributed system: tiered storage (hot HNSW + cold IVF-PQ), multi-region replication, hierarchical clustering, and quality monitoring per shard. Almost no team needs to operate at this tier — but if you do, Milvus, Vespa, and Vertex AI Vector Search are the proven options.

A mid-market fintech we worked with in 2025-2026 ran a customer-facing financial-document RAG system over a corpus that grew from 800K to 50M chunks in 14 months (10-K filings, earnings transcripts, analyst notes, news). They started on pgvector running on Neon Postgres because their core app was already Postgres and their team had zero ops appetite. At 800K vectors with 1024-dim Voyage embeddings, p99 sat at 12ms and the whole retrieval stack was a single SQL query joining metadata filters with the HNSW index — beautiful. They held this architecture until ~5M vectors. Past that, ingest pressure during nightly re-embedding started competing with read traffic, p99 climbed to 80ms during business hours, and the team began babysitting maintenance_work_mem and HNSW build parameters weekly.

At 8M vectors they migrated to Pinecone serverless. The migration itself took about three weeks: dual-writing to both stores for two weeks while validating recall parity on a 5,000-query gold set, then a clean cutover. Pinecone gave them sub-10ms p99 again, native namespaces for the 200+ enterprise tenants they were onboarding, and removed the operational tax — but the cost curve started biting hard around 25M vectors as read units scaled with their fast-growing query volume (their bill went from ~$2.4K/month to ~$11K/month over six months, and the projection at 50M vectors was ~$32K/month).

At 35M vectors they migrated again to self-hosted Qdrant on three c7i.4xlarge nodes (running about $1,800/month all-in, including S3 backups). The trigger was not technical dissatisfaction with Pinecone — recall and latency were excellent — but pure unit economics: Qdrant's payload filtering, native sharding, and binary quantization let them hit the same SLA at roughly 18% of the managed cost. The lesson is one we see constantly: the right vector DB at 1M is rarely the right one at 50M, and the migration cost is real but bounded. Picking a vendor with clean export tooling matters more than picking the "best" vendor on day one. See our RAG architecture guide for the dual-write migration pattern they used.

Pure dense vector search is wrong about 8-15% of the time on real queries — it confidently returns semantically similar but lexically wrong results, especially for proper nouns, codes, IDs, and rare technical terms. The 2026 production answer is hybrid search: run BM25 (lexical) and dense vector (semantic) in parallel, fuse the scores with Reciprocal Rank Fusion (RRF) or a learned weighted sum, then send the top-50 to a cross-encoder reranker for the final top-10. This three-stage pipeline (lexical + dense + rerank) is now the default for every serious RAG system we deploy.

The reranker is the part teams most often skip and most often regret. Cohere Rerank 3.5 and Voyage Rerank-2 are the two best closed-source options in 2026, with open alternatives like BGE Reranker v2-M3 and mxbai-rerank-large-v2 close behind. A reranker scores each (query, candidate) pair with a full cross-attention forward pass — much more expensive per pair than a dot product, but vastly more accurate. Reranking the top-50 candidates from hybrid retrieval typically lifts NDCG@10 by 8-20% over plain hybrid, and 15-30% over plain dense. The reranker costs roughly $1-$2 per 1M reranked pairs at managed pricing — material at scale, free at low volume.

Latency budgeting matters: a typical hybrid + rerank stack adds 50-200ms over plain dense retrieval (BM25 in 5-15ms, dense in 5-15ms, rerank top-50 in 30-150ms). For interactive chat (target: under 1 second to first token) this is fine. For autocomplete or sub-100ms paths it is not. The standard escape hatch is to skip the reranker for the bottom 80% of queries (low ambiguity, single-intent) and only invoke it when the top-K dense scores are clustered close together — a cheap classifier or score-gap heuristic. See our RAG concepts guide for the full hybrid architecture and code patterns.