Dora NodaAn AI agent without memory is a goldfish. Every tool call starts from zero: it re-reads the same docs, re-derives the same conclusions, and bills you for the tokens every single time. The fix is well understood — give the agent a vector store for retrievable, persistent memory — but for teams running on a self-hosted git-push PaaS, the next question is harder: which vector store do you run on machines you own, and what does each choice actually cost?
Three self-hostable engines dominate every 2026 comparison, with materially different tradeoffs. Here is the verdict up front, with the evidence below:
| Qdrant | Weaviate | pgvector | |
|---|---|---|---|
| Written in | Rust | Go | C (Postgres extension) |
| Query latency at 1M vectors (p50, HNSW) | ~19ms | ~22ms | ~45ms |
| Throughput at 1M vectors | ~900 QPS | ~780 QPS | ~320 QPS |
| Memory per 1M 768-dim vectors | ~2.5–8GB, down to 1/32 with binary quantization | ~8–10GB | Bound by Postgres shared buffers; index must fit in RAM |
| Hybrid keyword + vector search | Via sparse vectors, native hybrid API | First-class: BM25 + vector in one call | DIY: SQL union + RRF |
| Extra infrastructure | One stateful service | One stateful service | None if you already run Postgres |
| Self-hosted cost at 1M vectors | ~$40/mo (single VPS) | ~$40–80/mo | Marginal bump to the existing Postgres bill |
The managed alternative for reference: Pinecone Serverless lands around $50–260/mo at the same scale, and one documented self-hosted RAG build measured over 91% cost savings versus managed vector stores at equal recall. So self-hosting wins on price almost everywhere — the real decision is which engine earns a slot on your fleet.
Why agent memory is a platform primitive, not an app detail
A stateless agent loop works until the second session. Then the costs compound: re-embedded documents on every run, no recall of user preferences or past tool results, and context windows stuffed with re-fetched text at full token price. Persistent memory — past conversations, tool outputs, and domain knowledge, all retrievable by meaning — turns the agent from a clever chatbot into something that accumulates competence.
Every tenant on a PaaS hits this wall independently. That makes vector storage a platform-level concern, sitting naturally next to the Postgres and Redis/Valkey add-ons a git-push platform already provisions. The question is which engine becomes the one-click default — and which stays a bring-your-own integration.
Qdrant: the fastest engine, and the cheapest to feed
Qdrant is written in Rust and it shows: independent benchmark suites consistently place it at the top for latency and throughput per dollar self-hosted, with one 2025 ann-benchmarks run recording 98.7% recall at 1,420 QPS on a million vectors. Its second advantage is filtering — payload filters (match a tenant id, a document type, a timestamp range before the vector search) are a first-class citizen, which is exactly the access pattern tenant-owned memory needs: "search my documents, not everyone's."
Its third advantage is quantization flexibility. Qdrant supports scalar, product, and binary quantization with rescoring: binary quantization compresses each float component to a single bit, cutting memory up to 32x with a small recall cost, while the newer TurboQuant mode compresses about 8x at 4-bit precision with recall close to scalar quantization. In practice this means a $40/month VPS can serve 10M quantized vectors at sub-10ms p99 — the number that makes Qdrant's "60–80% cheaper than Pinecone at equivalent scale" reputation concrete rather than marketing.
The operational surface is one stateful service with an official Helm chart, gRPC plus REST APIs, and on-disk vector storage options for collections that exceed RAM. It is the most infrastructure you will run of the three options — but it is still one service, not a distributed system.
Weaviate: when the agent must match exact terms, not just meaning
Pure vector search has a blind spot: it matches meaning and fumbles exact strings — SKUs, error codes, proper nouns, version numbers. Weaviate's answer is hybrid search as a first-class API: one query combines BM25 keyword scoring with vector similarity, no hand-rolled fusion logic in your app. For an agent doing retrieval over technical docs or ticket histories, that combination retrieves things neither method finds alone.
Weaviate also ships the most built-in machinery around retrieval: generative search (RAG) and reranking modules inside the database itself, plus image search alongside text. The price is memory footprint — roughly 8–10GB per million 768-dim vectors in unoptimized deployments, the heaviest of the three — and throughput a notch below Qdrant (~780 vs ~920 QPS in head-to-head suites at 1M vectors).
Choose Weaviate when your tenants' agents live or die on hybrid retrieval quality and you would rather adopt the database's built-in RAG/rerank modules than assemble that pipeline from parts. Do not choose it for raw vectors-per-dollar; that contest belongs to Qdrant.
pgvector: the zero-infrastructure default with a known ceiling
pgvector's pitch is not performance — it is absence. If the platform already runs Postgres (and a git-push PaaS does), vector search arrives as CREATE EXTENSION vector: no new stateful service, no new backup story, no new operator to learn. Transactions, access control, and point-in-time recovery come free with the database you already operate. For agent memory under roughly a million vectors per tenant, it is not just adequate — independent suites measure 96%+ recall at hundreds of QPS, completely fine for conversational retrieval.
The ceiling is real and well documented, so plan for it explicitly:
- Dimension caps. The
vectortype indexes at most 2,000 dimensions;halfvecstretches to 4,000 at half the storage; binary vectors reach 64,000 dimensions via quantization. Modern embedding models at 768–1,536 dimensions fit comfortably; just verify before adopting a 4,096-dim model. - The RAM knee. The HNSW index must effectively live in RAM. Practitioners report a noticeable slowdown past 5–10M vectors per table, and 50M vectors lands in ~150GB RAM territory without extensions.
- Filtered search cliffs. Community investigations document pgvector's planner struggling with heavily filtered ANN queries around the low millions of vectors — precisely the tenant-scoped pattern agent memory uses. Test with your actual filter cardinality, not an unfiltered benchmark.
- DIY hybrid. Keyword-plus-vector means a SQL union of full-text search and vector search fused with reciprocal rank fusion, written and tuned by you.
The escape valve inside the Postgres family is pgvectorscale, which demonstrated 471 QPS at 99% recall on 50M vectors — but that is an extension on top of an extension, and by the time you need it you should be asking whether the workload has outgrown Postgres at all.
The scale sensitivity: who wins at 100K, 1M, 10M, 50M
The honest answer depends on the variable that drives everything: vectors per tenant.
- Under ~1M vectors: pgvector wins on total cost of ownership. Performance is fine, and zero new infrastructure beats every benchmark table.
- 1M–10M vectors: the crossover zone. pgvector still works with tuned indexes and generous memory, but filtered-query cliffs appear and the RAM budget starts to rival a dedicated service. Start tenants here on Postgres; migrate the hot ones.
- 10M–50M vectors: Qdrant's territory. Quantization keeps the RAM bill flat while recall stays above 95%, and payload filtering stays fast where pgvector's planner strains.
- Past ~50M vectors: dedicated engines only, with sharding and disk-backed indexes as explicit design decisions — or admit the tenant needs a specialist, not a platform default.
Note what this implies: the decision is per-tenant and changes over time, which is an argument for offering one default plus one escape hatch rather than blessing a single engine forever.
What "one-click vector memory" takes on a Cluster-API fleet
Provisioning the engine is the easy part. Each of the three has a Kubernetes-native path: Qdrant ships a Helm chart with clustering support, Weaviate ships one too, and pgvector rides whatever Postgres operator the platform already runs — CloudNativePG plus the extension, inheriting its backup and failover story untouched. A platform already operating Postgres therefore gets pgvector's control plane nearly free, while either dedicated engine adds one more stateful workload to monitor, back up, and upgrade.
The harder work is identical regardless of engine, and it is where "run a container" stops and "platform primitive" starts:
- Tenant isolation. Collection-per-tenant (Qdrant/Weaviate) or schema-per-tenant (pgvector), with the tenant id enforced in a filter the tenant cannot override — not by convention in app code. Cross-tenant vector leakage is the failure mode that ends platforms.
- Quotas. Per-tenant vector counts and QPS caps, so one tenant's bulk ingest cannot starve every other agent's recall latency on shared nodes.
- Lifecycle. TTL-based cleanup of stale memories and backup/restore scoped per tenant, because agent memory is user data subject to the same deletion requests as any other user data.
None of this is exotic — it is the same multi-tenancy discipline the platform already applies to Postgres databases and Redis keyspaces. Budget one operator plus the isolation layer, not just a Helm install.
The recommendation
For a git-push PaaS that already runs a Postgres operator: make pgvector the default and Qdrant the escape hatch. pgvector covers every tenant up to the low millions of vectors with zero new infrastructure, which is nearly every agent-memory workload in year one.
Offer Qdrant as the one-click upgrade for tenants crossing ~10M vectors or needing heavy filtered search — its quantization economics and payload filtering are worth a second stateful service exactly when Postgres stops being cheap. Reach for Weaviate when hybrid keyword-plus-vector retrieval is the product requirement rather than a nice-to-have, and let its built-in RAG modules replace pipeline code you would otherwise write.
The deeper point: agent memory is following the same path every PaaS primitive walks — from "each app wires its own" to "the platform provisions it per tenant." The platforms that ship the default early get to set the isolation and quota semantics before ten tenants invent ten incompatible ones.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
