Vector Database or Memory Layer: Which One Does Your Agent Actually Need?

They aren't competitors — one runs inside the other

Search for "agent memory" and you'll get pgvector, Pinecone, Qdrant, Milvus, Weaviate and Chroma in the same breath as Mem0, Zep and Cognee. They get compared as if a team has to choose one. They don't, because they're not doing the same job.

A vector database answers one question: given this embedding, what's nearest to it. It has no opinion on whether a fact is still true, whether two memories contradict each other, or whether last Tuesday's preference should override last month's. A memory layer answers a different question: given everything this agent has seen, what does it need to know right now. That requires extraction, deduplication, and often temporal reasoning — none of which a raw index provides.

The two aren't layered by accident; check what the memory tools actually run on. Mem0's self-hosted stack ships as three Docker containers, and one of them is PostgreSQL with pgvector — the vector database is a dependency, not an alternative (Mem0 self-hosting guide). Zep's memory engine, Graphiti, combines semantic embeddings with a temporal knowledge graph in Neo4j, using vector search as one retrieval channel alongside BM25 and graph traversal, not as the whole system (Zep on temporal knowledge graphs). Cognee's pipeline embeds chunks into a vector store as one of three steps in its extract-cognify-load process, then runs a separate "Memify" pass that prunes and reweights the resulting graph (Cognee memory architecture). Buy a memory layer and you get a vector database bundled inside it, plus an LLM pipeline deciding what goes in and what gets forgotten. Buy a vector database and you get the index, and you write that pipeline yourself.

So the real decision is about what your agent does. If it retrieves — RAG over documents, semantic search, recommendations — you want the index by itself, and adding a memory layer on top is unnecessary machinery. If it needs to accumulate and revise what it knows about a user or a running task across sessions, you want the extraction and consolidation logic, and hand-rolling that on a bare vector store is the harder path.

The vector database layer

All six of the vector-focused tools in our index are actively maintained — every one had a commit or release within the past week as of today (pgvector, Qdrant, Milvus, Weaviate, Chroma), so abandonment isn't the filter here. Licensing and hosting model are:

• pgvector — a Postgres extension, not a hosted product. Permissively licensed (the PostgreSQL License, functionally BSD-like), 22,667 GitHub stars, last pushed 2026-08-15. There's no separate bill: you run it inside whatever Postgres instance you already have.
• Pinecone — closed-source, managed only, no self-host path. Starter is free; Builder is $20/month flat; Standard is $50/month; Enterprise is $500/month (verified 2026-08-19).
• Qdrant — Apache-2.0, 34,054 stars, pushed 2026-08-18. Free tier is genuinely free forever (1GB RAM / 4GB disk, self-host or cloud), Standard tier is pure usage-based with no published flat number, Premium requires a minimum spend.
• Milvus — Apache-2.0, 45,685 stars (the most-starred pure vector database in our index), pushed 2026-08-19. Milvus itself has no vendor pricing — it's self-hosted software. The primary managed option, Zilliz Cloud, lists Serverless from $0/month and Dedicated from $126/GB/month (verified 2026-08-19).
• Weaviate — BSD-3-Clause, 16,739 stars, pushed 2026-08-19. Its "free" tier is a 14-day trial, not a permanent free plan like Qdrant's or Pinecone's. Paid tiers start at $45/month (Flex) and $400/month (Premium), both usage-scaled from that floor.
• Chroma — Apache-2.0, 29,082 stars, pushed 2026-08-19. Starter is $0/month plus usage (with $5 in free credits), Team is $250/month plus usage — a noticeably higher entry point than the others once you're past the free tier.

Read those together and the shape is: Milvus has the largest open-source community, pgvector has no separate cost at all if you're already on Postgres, and Pinecone is the only one of the six with no self-hosted escape hatch if you ever want to leave.

The pgvector threshold

If you already run Postgres, start with pgvector. That's not a hedge — it's the cheapest and lowest-effort option by a wide margin, because it adds no new service, no new bill, and no new operational surface. The open question is when that stops being true.

pgvector's own documentation is candid about where the friction starts: by default, PostgreSQL warns that the "hnsw graph no longer fits into maintenance_work_mem after 100,000 tuples" and that builds will take significantly longer once it spills to disk — a number small enough that most teams hit it without meaning to, well before a real production dataset (pgvector README). Raising maintenance_work_mem (Neon's engineering team recommends 8GB as a starting point) and using parallel index builds — a pgvector 0.6.0 feature — gets you much further; Neon benchmarked a 10-million-vector, 1,536-dimension index build on a 64 vCPU instance to show the improvement (Neon: pgvector index build performance). Past the low millions, an index build that used to take minutes starts taking hours, and you're actively managing memory and index maintenance rather than just querying.

Beyond that, there are two paths, not one. Timescale's pgvectorscale extension — a separate, disk-oriented DiskANN index that layers on top of pgvector — got PostgreSQL to 471 queries/second at 99% recall against 50 million 768-dimension vectors, beating Pinecone's storage-optimized tier on both latency and throughput in their own benchmark (Tiger Data: pgvector vs. Pinecone). So Postgres genuinely can scale to tens of millions of vectors — but only by adding a second extension and taking on the index tuning yourself, not by staying on vanilla pgvector. The honest threshold: vanilla pgvector is comfortable into the single-digit millions on one reasonably sized instance; past roughly 5–10 million vectors, decide whether you want to keep investing in Postgres tuning (pgvectorscale, partitioning, more RAM) or hand the problem to a database built for that scale from the start. If you don't have in-house Postgres operations experience, or you need guaranteed sub-10ms latency under high concurrency without babysitting an index, that's the point to move to Qdrant, Milvus or Weaviate instead of tuning your way further.

The memory layer

Mem0, Zep and Cognee all solve the same problem — persistent, evolving memory for an agent across sessions — with different architectures and, as of today, meaningfully different maturity:

• Mem0 — Apache-2.0, 63,561 GitHub stars, pushed 2026-08-18: the most active and most widely adopted of the three by a large margin. Extracts atomic facts from conversation via an LLM, then decides to add, update or delete against existing memories, writing to both a vector store and an optional graph store in parallel. Pricing: Hobby is free, Starter is $19/month, Pro is $249/month, Enterprise is custom (verified 2026-08-19).
• Zep — cloud-only. Zep deprecated its self-hosted Community Edition in 2025, with further feature retirements in February 2026; the open-source engine behind it, Graphiti, is still actively developed (30,071 stars, pushed 2026-08-18) but self-hosting the full temporal-graph product now means standing up Graphiti and a Neo4j instance yourself rather than running "Zep" as shipped (Zep's open-source strategy update). Pricing has a free tier (10,000 credits/month, 2 projects) but then jumps straight to $125/month (Flex) or $375/month (Flex Plus) — no tier in between for a team that's outgrown the free plan but isn't ready for a three-figure monthly bill.
• Cognee — Apache-2.0, 30,113 stars, pushed 2026-08-18. Fully self-hostable, and says so on its own pricing page. Runs ingested content through an extract-cognify-load pipeline that chunks, embeds and extracts entities/relationships, then a separate refinement pass prunes stale graph nodes over time. Pricing shifted to usage-based since it was last reviewed: Free includes one workspace and 1 million tokens with no card required, Standard is $2.50 per million tokens processed plus $5 per additional workspace per month, Enterprise is custom (verified 2026-08-19).

For most teams the default is Mem0: it's the most mature by every maintenance signal here, has the lowest committed cost to start ($19/month once you're past free), and both self-hosted and managed paths are first-class. Reach for Zep specifically when you need genuine temporal reasoning — "what did the user believe on this date, and when did that change" — since that's what its bi-temporal graph is built for, and accept that you're buying a cloud service, not open-source software, if you want the full product. Cognee is the pick if self-hosting matters to you as a hard requirement rather than an option, or if your usage is spiky enough that pure pay-per-token beats a flat monthly floor.

The bottom line

Don't compare these ten head to head — compare within the layer you actually need. For retrieval: pgvector if you're already on Postgres and staying under roughly 5–10 million vectors, Qdrant or Milvus if you want a dedicated open-source database with a genuinely free tier and a self-host option, Pinecone only if you're fine never being able to self-host. For memory: Mem0 by default, Zep if temporal reasoning is the actual requirement and you're comfortable being cloud-only, Cognee if self-hosting is non-negotiable.