Mem0 migrates 400M+ agent memories from pgvector to turbopuffer
Postgres didn't scale for Mem0's agent memory platform. They migrated hundreds of millions of memories to turbopuffer, reducing end-to-end latency by 70x.
agent memories
lower latency
97%
avg recall@10
The biggest benefit of turbopuffer is the peace of mind that we won't fall over as we scale.
Deshraj Yadav, Co-founder & CTO
Mem0 is building universal memory infrastructure for AI agents. Their open source memory framework achieves very high accuracy on common agent memory benchmarks (92.5 on LoCoMo, 94.4 on LongMemEval, 64.1 on BEAM 1M) while being 60% more token-efficient than other memory systems.
Mem0 first built a semantic search index for memory retrieval on pgvector, as they already ran Postgres in production on AWS Aurora. They stored all agent memories in a single Postgres table with an HNSW index for vector search.
Mem0's managed platform is multi-tenant, so queries must be scoped down to the
(organization, project, user, agent, session) level, requiring semi-selective
filtering on identity attributes. That forced Postgres to choose between walking
the HNSW index and postfiltering candidates, or prefiltering rows and ranking
them directly. With semi-selective filters, the options are hard to balance in
practice. Postfiltering can be selective enough that you walk the index for a
long time before finding enough candidates that match the filter. Prefiltering
exhaustively ranks whatever rows remain after the identity filters: fast when
that set is small, but painfully slow when the filters aren't selective enough.
As Mem0's Postgres table grew to hundreds of millions of memories, tail latency
spiked as high as 14s
under load. At this scale Postgres settled on the prefilter plan, which meant it
wasn't using the HNSW index at all. Vector writes and indexing (for an unused
index!) also slowed their transactional queries, with INSERT operations taking
800ms on average.
Mem0 had reached a scale where Postgres no longer felt like the right database for their semantic search workload, so they migrated embeddings to turbopuffer.
Why turbopuffer?
turbopuffer's architecture allows for high-recall, low-latency semantic retrieval even with complex attribute filtering, regardless of overall scale.
-
Dedicated index per customer: Mem0 builds a separate search index for each customer in a dedicated turbopuffer namespace. That physically isolates data by customer (good for security) and removes the semi-selective identity prefiltering that made Postgres discard the index, as each query runs against the dedicated index (good for performance). Each new namespace is just another prefix on object storage, so Mem0 can scale them virtually without limit and store millions of memories in each.
-
Index-aware attribute filtering: Mem0 stores entity attributes, timestamps, categories, and other metadata as non-vector attributes in turbopuffer. Instead of filtering before or after ANN retrieval, turbopuffer's index-aware filtering applies attribute filters during ANN retrieval. The index only considers candidates that match the filter, delivering high recall without the latency tradeoffs of postfiltering or prefiltering in Postgres.
-
Hybrid search: Mem0 indexes embeddings and text on turbopuffer. Semantic search finds candidate memories that match a query conceptually, while BM25 full-text search scores candidates that also share matching keywords with the query. Mem0 combines both vector distance and BM25 score signals via hybrid search and reranks them to produce the most relevant results.
-
Strong read consistency: Memories are continuously added, corrected, and forgotten. If an agent can't remember a fact it just wrote, it doesn't have a good memory system. turbopuffer's strong read consistency guarantees a new memory or update is retrievable immediately after it is committed.
turbopuffer's hybrid and attribute filtering search primitives let us model agent memory far more effectively than with embeddings alone.
Deshraj Yadav, Co-founder & CTO
Results
turbopuffer delivers consistent performance as Mem0 scales. Hybrid retrieval latency has consistently remained below 100ms — with tail latencies rarely exceeding 1s — even as Mem0 has scaled to 3TB+ of embeddings on turbopuffer.
- 70ms p90 hybrid retrieval latency on turbopuffer
- 97% average vector recall@10
- 150k+ customers, each with an isolated search index
- Scaled from 100M → 400M+ memories without latency increase or recall drop
Migrating embeddings and dropping the pgvector HNSW index also relieved their production Postgres instance, especially on write latency:
| Operation | Before | After | Reduction |
|---|---|---|---|
INSERT | ~800ms | 8.12ms | 99x |
UPDATE | ~500ms | 13.7ms | 36x |
SELECT | ~50ms | 13.4ms | 3.7x |
turbopuffer in Mem0
Mem0 is open source, and its memory layer can plug into any backing search engine. Mem0 Platform, the managed service, runs on turbopuffer.
Mem0 writes memory text, metadata, and a ref ID to both Postgres and turbopuffer, while embeddings are stored and indexed only in turbopuffer. Each customer gets a dedicated turbopuffer namespace with isolated vector, full-text, and attribute indexes for search.
To find a memory, Mem0 runs hybrid vector + full-text search queries with native attribute filtering on turbopuffer, then fetches the details of matching memories from the main memories table in Postgres using the ref ID.
┌──────┐
│writes│
└──────┘
│
┌──────┴──────┐
│ │
▼ ▼
╔═ pg ═══╗ ╔═ tpuf ═╗
║┌──────┐║░ ║┌──────┐║░
║│ mems │║░ ║│vector│║░
║└──────┘║░ ║└──────┘║░
╚════════╝░ ║┌──────┐║░
░░░░░░░░░░ ║│ BM25 │║░
▲ ║└──────┘║░
│ ║┌──────┐║░
│ ║│ attr │║░
│ ║└──────┘║░
lookup ╚════════╝░
│ ░░░░░░░░░░
│ ▲
│ │
│ hybrid/
│ filter
│ ┌───────┐ │
└──│queries│──┘
└───────┘
We will continue to update this log as Mem0's turbopuffer usage evolves.
