Vector Databases & Memory
A vector database stores embeddings and serves approximate nearest-neighbor (ANN) search, which finds the closest vectors to a query vector quickly using index structures like HNSW (graph-based, the most common) or IVF/IVF-PQ (cluster + quantize, memory-efficient at scale). The real production differentiators are rarely raw ANN speed. They're metadata filtering (can you say "similar and tenant=X and date>Y" efficiently?), hybrid search support, horizontal scale, operational burden, and cost.
Comparison (as of July 2026)
| Tool | What it is | Hosting | Scale sweet spot | Filtering / hybrid | Cost | Gotcha |
|---|---|---|---|---|---|---|
| pgvector | Postgres extension for vector search | Self-host or any managed Postgres (RDS, Supabase, Neon) | Up to ~single-digit to tens of millions of vectors comfortably | SQL WHERE + full-text = true hybrid in one DB |
Free extension; pay for Postgres | ANN recall/latency degrade at very large scale vs. dedicated engines; tune HNSW params |
| Pinecone | Fully managed, serverless vector DB | Managed cloud only | Very large, hands-off | Strong metadata filtering; hybrid supported | Usage-based (serverless), can get pricey at scale | Proprietary/closed; no self-host, vendor lock-in |
| Qdrant | Open-source vector DB in Rust | Self-host or Qdrant Cloud | Large, filter-heavy workloads | Excellent payload filtering; hybrid/sparse support | OSS free; managed cloud usage-based | You operate it if self-hosting |
| Weaviate | Open-source vector DB w/ built-in modules | Self-host or Weaviate Cloud | Medium to large, semantic apps | Hybrid (BM25+vector) first-class; GraphQL | OSS free; managed usage-based | GraphQL learning curve; schema up-front |
| Milvus | OSS vector DB built for massive scale (Zilliz) | Self-host or Zilliz Cloud | Billions of vectors, distributed | Filtering + hybrid; many index types | OSS free; Zilliz Cloud usage-based | Heavier to operate; overkill for small apps |
| Chroma | Lightweight, developer-first embedding DB | Local/embedded or Chroma Cloud | Prototyping to small/medium prod | Metadata filtering; hybrid maturing | OSS free; managed cloud | Not aimed at billion-scale distributed workloads |
| Redis | In-memory DB with vector sets/indexes | Self-host or Redis Cloud | Low-latency serving at moderate scale | Metadata filtering; hybrid via RediSearch | OSS free; managed cloud | Memory-bound; strongest fit when you already run Redis and want the latency |
| MongoDB Atlas Vector Search | Vector search bolted onto MongoDB | Managed (Atlas) | Medium, alongside your document data | Mongo-query filtering; hybrid | Atlas usage-based | Tied to Atlas, not a standalone engine |
| Elasticsearch / OpenSearch | Vectors added to a document/search store | Self-host or managed | Medium to large, search-heavy | First-class lexical + vector hybrid | OpenSearch OSS; paid tiers | Heavier ops; best when you already run it |
| LanceDB | Embedded, columnar vector DB | Local/embedded or cloud | Local to small/medium, analytics-adjacent | Filtering; hybrid maturing | OSS free | Younger ecosystem; not billion-scale distributed |
Also worth knowing: Vespa (mature OSS engine for large-scale hybrid search and ranking), turbopuffer (object-storage-first, aimed at big cost savings at scale), and the cloud-native managed options Azure AI Search and Google Vertex AI Vector Search for teams standardized on those clouds.
When to just use Postgres
If you already run Postgres, your corpus is in the low millions of vectors or fewer, and you value keeping vectors, metadata, and transactional data in one system with one backup story, pgvector is the reasonable choice. You get SQL filtering, joins, and hybrid search (with tsvector) without a second datastore to operate. Reach for a dedicated vector DB when scale (tens/hundreds of millions+), recall-at-latency SLOs, or multi-tenant filter performance push past what Postgres comfortably delivers. Many teams over-engineer this decision on day one.
Agent memory stores
"Memory" for agents is a layer above raw vector search. It decides what to remember, summarizes and consolidates it, expires stale facts, and retrieves the right memories per turn, spanning short-term (conversation state), long-term (durable facts about a user/task), and sometimes episodic/semantic distinctions. It typically sits on top of a vector DB plus a structured store. As of July 2026 the notable players:
| Tool | What it is | Best at |
|---|---|---|
| Mem0 | Open-source and hosted memory layer | Extracting and storing salient facts across sessions; popular for chat/agent personalization |
| Zep | Memory server with temporal knowledge-graph features (Graphiti) | Facts that change over time |
| Letta (formerly MemGPT) | Treats the LLM as an OS managing tiered memory | Self-editing memory and durable agent state |
| LangMem / LangGraph memory | Memory utilities within the LangChain ecosystem | Teams already on LangChain |
These are moving fast and benchmarks are contested. Prototype with one, but keep your memory interface thin so you can swap providers.