Single-plan fusion across vector, BM25, graph, and metadata, inside your existing Postgres. recall_fast() answers a synchronous agent turn at p50 22–46ms, p95 57–99ms on a live 7,612-lesson corpus, the first published p50/p95 latency we've found for SQL-native agent recall. Zero LLM cost per write, every score inspectable in plain SQL, every write able to prove its source.
Don't take our word for it, mark an outcome and watch recall re-rank itself, in SQL.
v0.10.0 adds recall_fast(), a pure-HNSW synchronous path that answers an agent turn at p50 22–46ms, p95 57–99ms (measured on a live 7,612-lesson corpus, 0% timeouts) and is now the MCP default. v0.10.1 hardens the recall_hybrid BM25 path (graceful vector-only fallback on timeout; p95 dropped 910ms→44ms on structured / non-Latin queries) and makes recall_fast reject a NULL embedding instead of returning NULL scores. Built on the outcome-learning loop (v0.7.0): every lesson carries a confidence score that reinforce() updates from each run’s outcome.
Pure HNSW vector recall, no BM25 scan and no graph BFS. p50 22–46ms, p95 57–99ms at k=10 on a 7,612-lesson live corpus, 0% timeouts, the first published p50/p95 we've found for SQL-native agent recall. 80% overlap@10 with full hybrid at 2–6.6× lower latency. Pass deep=true for full fusion.
pgmnemo.stats() gains a ghost_count column, lessons with no commit_sha and no artifact_hash. Alert when it exceeds your threshold, then flip gate_strict on.
When the bitemporal trigger closes+creates a row on a duplicate content_hash, ingest() now emits NOTICE: bitemporal close+create fired, closed N prior version(s). Parses out of psycopg2 connection.notices.
Lesson. A structured memory record that an AI agent writes to storage, for example «JWT tokens rotate after key compromise», annotated with the artifact that validated it (commit SHA, file hash, or passing test ID). The full noun pgmnemo operates on.
The problem. AI agents hallucinate. Today's memory systems store whatever the agent says, including hallucinated summaries, made-up commit IDs, and confident-but-wrong conclusions. Three weeks later, a different agent reads that bad lesson and builds on it. The mistake compounds across runs.
The fix. pgmnemo blocks that pattern with a provenance gate. Before any lesson is promoted to long-term memory, it must be attached to a verifiable artifact: a git commit_sha, a file hash, or a passing test ID. If no artifact exists, the lesson enters a staging queue, visible to queries but unflagged, and not surfaced to other agents. It promotes to canonical memory the moment an artifact is attached (commit SHA, file hash, test ID); until then it stays out of the trusted recall path.
Where it lives. Not a separate service or SaaS API. CREATE EXTENSION pgmnemo; in your existing PostgreSQL and you're done. The gate runs as a database-level row policy, application code cannot bypass it. Your data never leaves your server.
It produces an artifact, a git commit, a saved file, a passing test. That artifact is the proof the work is real.
ingest() requires commit_sha or artifact_hash. Without it the write is blocked at the database layer, not by your app.
recall_lessons() returns relevant past lessons using hybrid scoring: HNSW vectors + BM25 + recency + importance.
If three of these describe your project, pgmnemo replaces ~200 lines of ad-hoc memory code with two SQL function calls.
Every memory write logged with role + project + commit + timestamp at the database layer. Append-only, tamper-evident provenance, every write stamped with role, project, commit and timestamp, queryable directly in SQL.
| run | role | commit | at | trust |
|---|---|---|---|---|
| 8423 | dev | abc1234… | 14:22:01 | ✓ |
| 8424 | dev | def5678… | 14:22:05 | ✓ |
| 8425 | qa | NULL | 14:22:08 | ⚠ blocked |
1M context windows cost $5+ per call. pgmnemo retrieves the right 10K tokens instead of stuffing 1M. Memory ROI is positive after the first day at typical agent workloads.
JSONB → flexible metadata. pg_cron → automatic consolidation. Logical replication → multi-region HA. SaaS memory APIs have to build all this; pgmnemo inherits it.
Write-time artifact requirement enforced at the database layer. The only memory product with this, and the reason hallucinations stay out of canonical memory.
No daemons, no sidecars, no cloud accounts. CREATE EXTENSION pgmnemo CASCADE;, that's it. Memory lives where your data already does.
HNSW + BM25 + recency + importance, hybrid search and temporal ranking fused by rank, with no glue code and no re-ranker microservice, in one SELECT.
Multi-tenant from day one. role + project_id row-level security enforced inside Postgres, not by your app.
Hallucinated lessons cannot enter long-term memory. Every ingest() requires a verifiable artifact, git commit SHA, file hash, or test ID. Enforced at the database layer.
gate_strict=enforce fires BEFORE INSERT at the database trigger layer. SaaS memory providers (Mem0, Zep, Letta) accept writes via API, they cannot enforce write-time constraints because enforcement must happen at the storage layer, not the API layer. Application-side enforcement is bypassable; database-trigger enforcement is not.
| pgmnemo | mem0 | Zep | pgvector+glue | ParadeDB | LangMem | |
|---|---|---|---|---|---|---|
| Deployment | Postgres extension | SaaS API | SaaS API | DIY pipeline | Postgres extension | Python lib |
| Cost per write | storage only | per-call API | per-call API | storage only | storage only | LLM call per write |
| Synchronous recall latency | ✓ p95 57–99ms measured, k=10 | not published | not published | DIY | not published | not published |
| Point-in-time queries | ✓ as_of_ts | ✗ | ✗ | ✗ DIY | ✗ | ✗ |
| Provenance gate at write | ✓ enforced | ✗ | ✗ | ✗ | ✗ | ✗ |
| Data residency | your DB | Mem0 cloud | Zep cloud | your DB | your DB | in process |
| License | Apache-2.0 | Apache-2.0 + SaaS | Apache-2.0 + SaaS | PostgreSQL | AGPL | MIT |
Why ParadeDB isn't on this list as competition: ParadeDB is excellent at full-text search inside Postgres. pgmnemo is retrieval, it decides what an application should recall, with provenance, time validity, and ranking diagnostics. Different capability classes. pgmnemo sits next to ParadeDB in a Postgres install, answering different questions.
pgmnemo turns retrieval into a traceable, replayable, evidence-backed database operation. Every recalled fact carries provenance metadata: commit SHA, artifact hash, verification timestamp. Every retrieval decision produces a per-signal scoring diagnostics breakdown. Point-in-time retrieval via as_of() answers the regulator's question: "What did the system know when it made that recommendation?"
EU AI Act Articles 13–14 timelines are 2027+. pgmnemo is building the substrate now.
Search finds documents. Retrieval decides what an application should recall, with what confidence, as of when, and why. pgmnemo is building the category of governed retrieval: retrieval that runs inside the database transaction, enforces write-time provenance, respects temporal validity, and can explain its ranking decisions. This is the EXPLAIN ANALYZE moment for AI retrieval, the point where retrieval stops being a black box and becomes a debuggable, auditable database operation.
EXPLAIN RECALL, a dedicated function returning per-signal scoring diagnostics, is on the v0.6.x roadmap. The shipped precursor is the per-signal diagnostic columns vec_score, bm25_score, rrf_score already present in every recall_lessons() result row.
-- Store with provenance (required) SELECT pgmnemo.ingest( p_role := 'developer', p_project_id := 1, p_topic := 'auth', p_lesson_text := 'Rotate JWT after key compromise.', p_commit_sha := 'abc1234' ); -- Hybrid recall SELECT lesson_text, score, vec_score, bm25_score FROM pgmnemo.recall_lessons( query_embedding := embed('JWT rotation'), query_text := 'JWT secret rotation', role_filter := 'developer' ) ORDER BY score DESC LIMIT 10;
Evaluation benchmarks we run against: LongMemEval (arXiv:2410.10813), LoCoMo (arXiv:2402.17753).
LoCoMo measures recall on multi-session conversations. pgmnemo v0.10.1 reaches recall@10 = 0.8409 (+4.15pp vs v0.3.0, p_corr=0.0156). Reproducible with the DRAGON embedder per paper protocol.
Read paper ↗LongMemEval probes long-horizon retrieval on simulated user sessions. pgmnemo v0.10.1 reaches recall@10 = 0.9604 (sparse-safe RRF, bge-m3 1024d, p=0.017). A 50-line BM25 script reaches 0.9820 on this dataset. pgmnemo v0.10.1: 0.9604. Gap: −2.16 pp. We publish both.
Read paper ↗A 50-line BM25 script beats us by 2.16 pp. We publish this. The provenance gate is original work, not in this benchmark.
pgmnemo doesn't replace pgvector, it sits next to it, calling pgvector's HNSW for vector similarity. Your existing embeddings carry over. Add hybrid recall, temporal validity, and provenance enforcement without rebuilding your pipeline.
CREATE EXTENSION IF NOT EXISTS vector; CREATE EXTENSION pgmnemo CASCADE;
-- pgmnemo runs alongside pgvector; bring existing rows in via ingest(). no downtime. SELECT pgmnemo.ingest( p_role => 'system', p_project_id => 1, p_topic => 'import', p_lesson_text => content, p_embedding => embedding ) FROM your_embeddings;
Your pipeline keeps working. recall_lessons() becomes available alongside your existing pgvector queries. View full migration guide →
pgxn install pgmnemo
CREATE EXTENSION pgmnemo CASCADE;
FROM pgvector/pgvector:pg17
ADD pgmnemo-0.10.1.zip /tmp/
RUN apt-get update && apt-get install -y unzip \
&& unzip /tmp/pgmnemo-0.10.1.zip -d /tmp/ \
&& cp -r /tmp/pgmnemo-0.10.1/extension/* \
$(pg_config --sharedir)/extension/ \
&& rm -rf /tmp/pgmnemo-0.10.1* /var/lib/apt/lists/*
git clone https://github.com/pgmnemo/pgmnemo.git cd pgmnemo/extension && make && sudo make install
psql -c "CREATE EXTENSION pgmnemo CASCADE;"
MCP server for Claude, Cursor, custom AI agent hosts. No app-level code changes.
View on PyPI ↗pip install pgmnemo-mcp
The things people actually hit when wiring pgmnemo into a stack, embeddings, the provenance gate, upgrades. Answered straight, verified against the shipped extension.
Yes, with one hard requirement: pgmnemo stores exactly 1024-dimensional vectors. The schema declares embedding vector(1024) and ingest() rejects any other size.
bge-m3 (1024-dim, multilingual) is the validated default, it's what our benchmarks run on. Serve it from LM Studio's /v1/embeddings endpoint and use its dense output.
pgmnemo does not generate embeddings for you, you produce the vector and pass it to ingest() and recall_lessons(). Use the same model for writes and queries, or cosine similarity compares vectors from different spaces.
That's the provenance gate. By default it requires commit_sha or artifact_hash on insert, so every memory carries provenance. Control it with one setting:
SET pgmnemo.gate_strict = 'off'; -- disable SET pgmnemo.gate_strict = 'warn'; -- allow, but log a warning
Default is 'enforce'. You can also set it per database with ALTER DATABASE … SET pgmnemo.gate_strict = 'off'. Cleaner than turning it off: just pass commit_sha or artifact_hash on insert.
No, pgmnemo runs alongside pgvector and uses it for the dense vector column. You need pgvector ≥ 0.7.0 installed; CREATE EXTENSION pgmnemo CASCADE pulls it in automatically.
Install the new extension files, then run:
ALTER EXTENSION pgmnemo UPDATE;
This applies the migration chain to your existing data in place, no re-ingest needed.
Two common causes. First, the provenance gate (above): a lesson with no commit_sha and no artifact_hash while gate_strict='enforce', supply one of those fields, or relax the gate. Second, an embedding dimension mismatch, the vector must be exactly 1024-dim, or ingest() raises expected 1024, got N.
Direction, not commitments. We ship what we can verify with benchmarks first.
Promote per-signal diagnostic columns (vec_score, bm25_score, rrf_score) into a first-class explainer function. Returns an EXPLAIN-style structured breakdown of why each result ranked where it did. Today's shipped precursor is the diagnostic columns already in every recall_lessons() row.
gate_strict_per_tenant GUC for hybrid SaaS deployments where some tenants need enforce, others run in warn while their provenance corpus is bootstrapped.
Make mem_edge graph proximity a first-class signal in recall_lessons() alongside vector/BM25/temporal. The bitemporal graph layer is already in storage; graph proximity already ships as a multiplicative tie-breaker (v0.8.0); a first-class, equal-weight signal behind a full benchmark gate is next.
No dates. We benchmark before we promise.