Long-Term Memory in EvolutionDB — a technical series¶
Companion to the product piece.
This series goes underneath the marketing surface and walks through how EvolutionDB's agent-memory layer is actually built — every catalog object, every wire format, every index structure, every fsync.
It is intended for readers who want to know how, not just whether, it works: database engineers, agent-framework authors, and anyone considering running this in production.
The plan¶
Articles are written so each one stands on its own; you can drop into any of them without reading the others first.
The cast of files¶
For readers who want to follow along in the source tree, the relevant modules are:
evolution/db/memory_store.c—MEMORY STOREDDL/DMLevolution/db/checkpoint_store.c—CHECKPOINT STOREDDL/DMLevolution/db/vector.c—VECTOR(N)tuple encoding + distance functionsevolution/db/hnsw.c— HNSW graph indexevolution/db/mvcc.c— visibility predicate, snapshots, CSNevolution/db/temporal.c—FOR SYSTEM_TIME AS OFrewriteevolution/db/Notify.c+adaptor/notify.c—LISTEN/NOTIFYevolution/db/cdc.c+adaptor/cdc_server.c— durable subscriptionsclient/libevosql-memory/— C SDKclient/python-evosql-memory/— Python ctypes bindingclient/mcp-server-evosql/— Claude Desktop / Claude Code bridge
The full repository is at
github.com/alptekin/evolutiondb.
Tests for every feature discussed live under tests/, and each
article points at the exact test file that exercises the behaviour
it describes.
A note on tone¶
The product piece is written for a Medium audience and avoids internal identifiers on purpose. This series does the opposite — it names files, functions, page types, error codes, and on-disk layouts directly. If you came in looking for a feeling, the product piece is upstairs. If you came in looking for a hex dump, you're in the right place.