LLM Embeddings and Vector Databases: A Complete Guide

Introduction

Embeddings are the foundation of modern semantic search, retrieval-augmented generation, and recommendation systems. They transform text — words, sentences, paragraphs, entire documents — into dense vector representations that capture semantic meaning in a high-dimensional space. Two semantically similar texts will have vectors that are close together, while unrelated texts will be far apart. This property makes embeddings the interface between natural language and mathematical similarity search.

Vector databases are the storage and retrieval infrastructure for embeddings. They organise billions of vectors for efficient similarity search, supporting the fast approximate nearest neighbour (ANN) queries that power production AI systems. In 2026, the vector database market has matured significantly — a 2025 Gartner report estimated that over 60% of organisations deploying LLMs in production use a dedicated vector database, up from 25% in 2023 [1].

This guide covers the fundamentals of embeddings, the leading embedding models and their trade-offs, vector database internals including ANN algorithms and indexing strategies, a comparison of major vector DB platforms, and production deployment patterns for semantic search and RAG pipelines. For a primer on the underlying mathematics, see our guide on vectors, tensors, and scalars explained.

What Are Embeddings?

An embedding is a dense vector of floating-point numbers that represents a piece of text in a latent semantic space. Unlike sparse representations (bag-of-words or TF-IDF vectors, which are mostly zeros), dense embeddings pack semantic information into a compact vector — typically 256 to 3072 dimensions depending on the model. The key property is that the distance between vectors in this space corresponds to semantic similarity.

Embeddings are generated by neural encoder models, predominantly transformer-based architectures trained on contrastive learning objectives. The model is trained to produce similar vectors for semantically related text pairs and dissimilar vectors for unrelated pairs. OpenAI's text-embedding-3 models, for example, use a two-stage training process: contrastive pre-training on a massive corpus of text pairs, followed by instruction tuning to improve performance on specific tasks like clustering, classification, and search [2].

The mathematical foundation of embeddings is the same as the vector mathematics used throughout machine learning. For a detailed explanation of vector operations, dot products, and vector spaces, see our article on vectors, tensors, and scalars explained.

How Embeddings Capture Semantic Meaning

The geometry of embedding space encodes semantic relationships. The classic example is the "king - man + woman = queen" relationship in Word2Vec embeddings, where vector arithmetic reveals analogies. Modern LLM embeddings exhibit far richer structure: they encode synonyms, paraphrases, topic similarity, sentiment, and even stylistic similarity. The embedding of "I purchased a vehicle" will be closer to "I bought a car" than to "I ate breakfast" even though the first two share no words in common — this is semantic understanding, not keyword matching.

The semantic richness of an embedding depends on the model that produced it. Larger models with higher dimension counts capture more nuanced semantic distinctions but are more expensive to compute and store. The choice of embedding model is the most consequential decision in any vector search system — it determines what "similarity" means in your application and sets the upper bound on retrieval quality.

Popular Embedding Models

The embedding model landscape in 2026 offers choices across dimensions, cost brackets, and performance tiers. The key decision factors are embedding quality (measured by retrieval accuracy on benchmarks like MTEB and BEIR), dimension count (affects storage cost and search speed), inference cost (cost per million tokens), and latency.

OpenAI text-embedding-3 Series

OpenAI's text-embedding-3-small and text-embedding-3-large are the most widely used embedding models in production. text-embedding-3-small produces 1536-dimensional vectors at a cost of $0.02 per million tokens, with strong performance across MTEB benchmarks (average score of 62.3). text-embedding-3-large produces 3072-dimensional vectors at $0.13 per million tokens with an MTEB average of 64.6 — the highest among commercially available models [2]. Both support a "dimensions" parameter that allows truncating the output vector to any size (e.g., 256, 512, 1024) without recomputing the embedding, enabling flexible cost-performance trade-offs.

BGE (BAAI General Embedding)

BGE by BAAI (Beijing Academy of Artificial Intelligence) is the leading open-source embedding model family. BGE-large-en-v1.5 produces 1024-dimensional vectors with an MTEB average of 64.2 — competitive with OpenAI's text-embedding-3-large at zero inference cost if self-hosted. BGE-small-en-v1.5 produces 384-dimensional vectors (MTEB: 60.1) and runs efficiently on CPU. The BGE models support Matryoshka Representation Learning, allowing the same model to produce embeddings at multiple dimension scales. BGE is the dominant choice for self-hosted deployments where data privacy or cost control is paramount.

E5 and E5-Mistral

Microsoft's E5 family uses a contrastive learning approach with curated text pairs from web data. E5-large-v2 (1024 dimensions, MTEB: 62.6) is a strong middle-ground option. E5-Mistral-7b-instruct (4096 dimensions) pushes MTEB scores above 66, approaching proprietary model quality, but requires significant GPU resources for inference — a single 7B parameter embedding model is impractical for high-throughput applications. E5 models excel at retrieval tasks in particular, making them a top choice for RAG pipelines.

Voyage and Cohere

Voyage AI offers specialised embedding models optimised for code retrieval (voyage-code-3) and legal document search (voyage-law-3). Their general model, voyage-3-large (2048 dimensions), achieves strong MTEB performance (63.8) with competitive pricing. Cohere's Embed v3 models (1024 dimensions, MTEB: 63.2) offer multilingual support across 100+ languages and differentiate through their classification and clustering API endpoints. Both providers focus on enterprise features: data residency options, dedicated throughput, and SLAs.

Performance and Cost Comparison

The practical choice depends on your throughput requirements and budget. For applications serving fewer than 100,000 queries per day, API-based models (OpenAI, Cohere, Voyage) are cost-effective given their pay-per-token pricing. At higher volumes, self-hosting BGE or E5 on GPU instances becomes cheaper — the break-even point is typically around 1-5 million queries per day depending on the model size. For latency-sensitive applications, smaller models (BGE-small at 384 dimensions, text-embedding-3-small at 512 truncated dimensions) can reduce search latency by 40-60% compared to 3072-dimension vectors while retaining 90-95% of retrieval accuracy.

Vector Database Internals

Vector databases solve a fundamentally hard computational problem: finding the nearest neighbours to a query vector among billions of candidates in high-dimensional space. Exact nearest neighbour search is O(n) — it requires comparing every vector against the query. For any production-scale system, exact search is computationally infeasible. Vector databases use Approximate Nearest Neighbour (ANN) algorithms that trade a small amount of recall for massive speed improvements.

HNSW (Hierarchical Navigable Small World)

HNSW is the most widely used ANN algorithm in 2026, and for good reason. It constructs a multi-layer graph structure where each layer is a progressively sparser graph connecting nearby vectors. Search starts at the top layer (fewest nodes, coarsest connections) and descends through finer layers, routing the query toward its nearest neighbours at each level. HNSW achieves 95-99% recall at search speeds 10-100x faster than brute force, depending on the configuration parameters [3].

The key trade-off in HNSW is between recall and memory. The graph structure requires storing multiple edges per node — typically 32-128 edges per vector — which adds significant memory overhead. A collection of 1 million 1536-dimensional vectors (approximately 6 GB of vector data) requires an additional 2-8 GB for the HNSW graph structure. HNSW also supports incremental insertion (new vectors can be added without rebuilding the entire index) and deletion, making it suitable for dynamic datasets.

IVF (Inverted File Index)

IVF partitions the vector space into clusters (typically using k-means) and limits search to the nearest clusters to the query vector. During indexing, each vector is assigned to its nearest cluster centroid. During search, the query vector is compared against cluster centroids, and only the vectors in the nearest N centroids are searched. IVF with 4096 centroids searching the top 16 clusters reduces the search space by 256x compared to brute force.

IVF is less accurate than HNSW at the same search speed but uses significantly less memory — it stores only the cluster assignments (one integer per vector) rather than a full graph structure. IVF is the algorithm of choice for very large datasets where memory is the limiting factor, or for workloads where batch indexing (rebuilding periodically) is acceptable.

PQ (Product Quantization)

Product Quantization compresses vectors by partitioning them into sub-vectors and quantising each sub-vector independently using a learned codebook. A 1536-dimensional vector can be compressed from 6144 bytes (4-byte floats) to 96-384 bytes using PQ, a 16-64x compression ratio. PQ is almost always used in combination with another ANN algorithm — typically IVF-PQ or HNSW-PQ — where the index structure navigates to approximate neighbours using compressed vectors, and exact distances are computed only for the top candidates.

PQ is essential for billion-scale vector search. Without compression, storing 1 billion 1536-dimensional vectors requires 5.7 TB of RAM. With PQ at 64 bytes per vector, the same dataset fits in 64 GB — a 90x cost reduction. The trade-off is reduced recall: PQ compression typically loses 1-3% in recall at conservative compression ratios and 5-15% at aggressive ratios.

Indexing Trade-Offs Summary

The choice of ANN algorithm depends on your dataset size, update frequency, recall requirements, and memory budget. For datasets under 10 million vectors with frequent updates, HNSW is the default choice. For datasets over 100 million vectors, IVF-PQ or HNSW-PQ with aggressive compression is necessary. For datasets updated in real time, HNSW supports incremental insertion natively while IVF requires periodic index rebuilding. For batch-processed datasets (daily rebuilds), IVF provides the best performance-per-dollar ratio.

Distance Metrics

The distance metric defines what "similar" means in vector space. Three metrics dominate production use, each appropriate for different embedding characteristics and use cases.

Cosine Similarity

Cosine similarity measures the angle between two vectors, ignoring their magnitude. It ranges from -1 (opposite direction) to 1 (same direction) with 0 indicating orthogonality. Cosine similarity is the standard metric for text embeddings because most embedding models produce vectors whose magnitude correlates with token count rather than semantic content — two documents on the same topic have similar direction regardless of their length. Most production RAG systems use cosine similarity.

Dot Product

Dot product similarity (the unnormalised inner product) considers both direction and magnitude. It is the appropriate metric when embedding magnitude carries information — for example, in recommendation systems where higher-magnitude embeddings might indicate stronger user preferences, or in models trained explicitly with a dot-product loss function. Many modern embedding models (including OpenAI's text-embedding-3 series) are trained with dot product as the similarity objective, making it the theoretically correct metric despite cosine similarity being more common in practice.

Euclidean Distance (L2)

Euclidean distance measures the straight-line distance between two vectors. It is the most intuitive metric geometrically but the least commonly used for text embeddings because it is strongly affected by vector magnitude. When embeddings are L2-normalised (magnitude = 1), cosine similarity is equivalent to dot product and inversely monotonic with Euclidean distance, so the choice between them becomes computational rather than semantic. L2 distance is most appropriate for embeddings that are naturally magnitude-invariant, such as those produced by some graph embedding methods.

Vector Database Comparison

The vector database market has consolidated around five primary options, each with distinct strengths. The right choice depends on your scale, latency requirements, feature needs, and operational capabilities.

Pinecone

Pinecone is the leading managed vector database, offering the most mature serverless and pod-based deployments. It supports HNSW indexing with configurable ef_construction and M parameters, metadata filtering, sparse-dense hybrid search, and multi-tenancy through namespaces. Pinecone's key advantage is operational simplicity — it is fully managed with automatic scaling, backups, and 99.99% uptime SLA. The trade-off is cost: Pinecone is 2-5x more expensive than self-hosted alternatives at scale. As of 2026, Pinecone supports up to 5 billion vectors per index and offers integration with major embedding providers.

Qdrant

Qdrant has emerged as the leading open-source vector database for self-hosted deployments. It supports HNSW and custom payload indexing with rich filtering capabilities — including nested filter conditions, geo-search, and full-text search. Qdrant's key differentiator is its filtering performance: it maintains separate indexes for payload fields, allowing filtered vector searches without full index scans. Qdrant offers both managed cloud (starting at $25/month) and self-hosted (Docker, Kubernetes) deployment options, with binary quantization support for 4x memory reduction.

Weaviate

Weaviate differentiates through its built-in module system that integrates embedding, vectorisation, and generation directly into the database. You can configure Weaviate to auto-vectorise data using OpenAI, Cohere, or Hugging Face models, eliminating the need for a separate embedding pipeline. Weaviate supports hybrid search (combining vector and keyword search with weighted scoring), multi-tenancy, and cross-modal retrieval (text-to-image, image-to-text). It is the strongest choice for teams that want an all-in-one AI-native database rather than a pure vector store.

Milvus

Milvus is the most scalable open-source vector database, supporting trillion-scale deployments through its cloud-native architecture. It separates storage and compute, with independent scaling for data ingestion, index building, and query processing. Milvus supports all major ANN algorithms (HNSW, IVF, IVF-PQ, DiskANN), multiple index types per collection, and GPU-accelerated indexing for faster index builds. Milvus is the strongest choice for massive-scale deployments (10 billion+ vectors) but has the steepest operational learning curve.

pgvector

pgvector is a PostgreSQL extension that adds vector storage and similarity search to existing Postgres databases. It supports exact search via IVFFlat indexes and approximate search via HNSW indexes (added in pgvector 0.7.0). pgvector is the simplest option to deploy and the best choice for applications that already use PostgreSQL and cannot justify an additional infrastructure dependency. The trade-off is performance: pgvector is 2-5x slower than dedicated vector databases at scale, and its filtering capabilities are limited compared to Qdrant or Milvus.

Production Considerations

Moving from prototype to production with vector search introduces challenges around filtering, multi-tenancy, hybrid search, and re-ranking. These considerations often determine whether a vector DB deployment succeeds or fails under real traffic.

Metadata Filtering

Most production vector searches include metadata filters — "only search documents in English", "only documents from Q2 2026", "only documents with a confidence score above 0.8". The efficiency of pre-filtering (apply filters before vector search) versus post-filtering (vector search first, then apply filters) has a significant impact on latency and accuracy. Qdrant and Milvus support pre-filtering through their indexing architecture, allowing filtered searches to complete in milliseconds even with complex filter conditions. Pinecone and Weaviate support both modes but pre-filtering performance depends on cardinality.

Multi-Tenancy

Multi-tenant vector databases partition data so that each tenant (organisation, user, project) sees only their own vectors. The implementation strategy significantly impacts performance. The simplest approach is one collection per tenant, but this does not scale beyond a few thousand tenants — each collection incurs memory overhead for index structures. The better approach is a shared collection with a tenant_id payload field, using pre-filtering on the tenant_id to isolate queries. Qdrant's payload indexing makes this approach work efficiently even at hundreds of thousands of tenants.

Hybrid Search

Hybrid search combines vector similarity with keyword (BM25) matching, typically using a weighted sum of scores. This is essential for production search systems because vector search alone can miss exact keyword matches that users expect — searching for "Syntave API documentation" should prioritise the exact phrase match even if the semantic meaning is captured elsewhere. Weaviate and Qdrant support native hybrid search with configurable alpha weighting. For Pinecone and Milvus, hybrid search requires a separate keyword index (e.g., Elasticsearch) with a fusion layer.

Re-Ranking

Vector search retrieves a broad set of candidates (typically 20-100) using fast ANN search, and a cross-encoder re-ranker scores the candidates more accurately to select the top K (typically 3-5). This two-stage retrieval significantly improves relevance: cross-encoder re-rankers like BGE-reranker-v2 or Cohere Rerank achieve 5-15% higher NDCG@10 compared to vector search alone [4]. The re-ranker should be run on the candidate set after filter application, and it must be fast enough to not dominate query latency — typical re-ranking adds 50-200ms depending on model size and candidate count. For a deeper treatment of re-ranking within RAG pipelines, see our guide on best RAG practices.

Embedding and Search Pipeline Example

The following code demonstrates a complete embedding and vector search pipeline using OpenAI embeddings and Qdrant. This pattern — embed, store, query, re-rank — is the foundation of almost every production vector search system.

import { OpenAI } from "openai";
import { createClient } from "@syntave/client";

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
const vectorDb = createClient({
  provider: "qdrant",
  apiKey: process.env.QDRANT_API_KEY,
});

async function searchSimilar(query: string, topK = 5) {
  const response = await openai.embeddings.create({
    model: "text-embedding-3-small",
    input: query,
  });
  const embedding = response.data[0].embedding;

  const results = await vectorDb.query({
    collection: "documents",
    vector: embedding,
    limit: topK,
    withPayload: true,
  });

  return results;
}

In production, this pipeline would be extended with: batch embedding for ingestion (processing hundreds of documents per minute), caching for frequently searched queries, hybrid search with BM25 scores, a cross-encoder re-ranking stage, and monitoring for retrieval quality (recall@k, MRR, NDCG). For a comprehensive architecture, see our article on abstracting the RAG pipeline and our guide on best RAG practices.

For multi-tenant systems, the filter parameter enables tenant isolation:

const results = await vectorDb.query({
  collection: "documents",
  vector: embedding,
  filter: {
    must: [
      { key: "tenant_id", match: { value: "org_123" } },
      { key: "language", match: { value: "en" } },
    ],
  },
  limit: 20,
  withPayload: true,
});