Analysis updated 2026-07-26
Give a chatbot persistent memory across conversations without a third-party service.
Store and recall agent decisions, preferences, and facts with automatic deduplication.
Search an agent's memory by meaning, keywords, or named entities like people and projects.
Keep a full history of how facts change over time without deleting old information.
| reescalder/agent-memory-supabase | omarish/llm-sql | saiprajoth/timescaledb-lab | |
|---|---|---|---|
| Stars | 2 | 1 | 1 |
| Language | PLpgSQL | PLpgSQL | PLpgSQL |
| Setup difficulty | moderate | moderate | moderate |
| Complexity | 3/5 | 4/5 | 3/5 |
| Audience | developer | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires a Supabase project with the pgvector extension enabled, installation is by cloning the repo directly since it is not on npm yet.
{"i":0,"repo":"reescalder/agent-memory-supabase","stars":2,"lang":"PLpgSQL","ok":true,"char_count":1725,"text":"This project gives AI agents a long-term memory system built entirely on top of a standard Postgres database hosted through Supabase. Instead of relying on a separate service that sits between your agent and its stored knowledge, you get a single database table, a handful of SQL functions, and a small JavaScript client. The core idea is that you fully own and can inspect the underlying data and logic at all times.\n\nWhen an agent stores a new memory, the system first checks whether a near-identical memory already exists. It does this in two ways: by comparing meaning using vector embeddings, and by comparing text patterns using a Postgres feature called trigram matching. If a match is found, the existing memory is updated in place rather than creating a duplicate row. This keeps the memory store clean without needing a separate cleanup process.\n\nRecalling memories works through three independent search lanes that are then combined into one ranked list. The first lane compares meaning using vector similarity. The second uses traditional full-text keyword search. The third is an entity lane that pulls up memories related to specific people, projects, or tools named in the query. A ranking formula called Reciprocal Rank Fusion merges the results from all three lanes. Small adjustments for recency, importance, and how often a memory is used affect the final ordering.\n\nMemories are organized into nine types, including fact, decision, preference, correction, and event. The type matters because it changes how the memory is treated. Preferences and corrections never lose ranking priority over time. Transcripts are kept out of keyword search. Facts also carry a timeline, so when information changes, the old fact is marked as superseded rather than deleted, preserving full history.\n\nThe author built this after running a similar system in production with over 22,000 stored memories. The code includes practical notes about real bugs encountered, such as why a specific function overload quietly broke the deduplication logic for months. The project is not yet published to npm, so installation is done by cloning the repository directly. The full README is longer than what was shown.","error":null}
A long-term memory system for AI agents built on Supabase Postgres. Agents store, deduplicate, and recall memories using vector search, keyword search, and entity matching, all with full data ownership.
Mainly PLpgSQL. The stack also includes PLpgSQL, PostgreSQL, Supabase.
No license information is provided in the repository, so usage rights are unclear.
Setup difficulty is rated moderate, with roughly 30min to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.