Why I Put Swarm Memory in PostgreSQL Instead of Zep

The project allocated roughly 30,000 to 40,000 credits per simulation for memory usage. Daily runs would turn memory retrieval into a recurring external dependency before the gateway had served its first reader. To resolve this issue, the memory layer was moved into PostgreSQL 16 with pgvector. The upstream checkout still utilized its configured graph provider while constructing a graph.

However, the boundary was now closer and more defensible: once MiroFish returned graph data and action logs, the gateway owned the persisted copy and every read against it. The gateway had three read patterns: retrieving entities by type, walking a bounded neighborhood, and searching agent episodes by meaning. These patterns were met by adding graph nodes, graph edges, and episodes to the existing PostgreSQL database. pgvector facilitated semantic queries without introducing another network call.

The tenant rule was made explicit, with tenantId and simulationId included in the graph tables and unique constraints preventing duplicate records within a simulation. The schema consisted of one store and two kinds of memory: graph entities and agent episodes. Graph entities mirrored named entities from the MiroFish graph, while agent episodes stored actions produced during simulation rounds.

The embedding width was set to 384 dimensions, matching the output of the local Xenova/all-MiniLM-L6-v2 model. The embedding extractor was initialized lazily and shared through a single promise to avoid loading the ONNX model for non-semantic search requests and prevent concurrent model loads. The query function, which carries the security contract, performed semantic retrieval using cosine similarity, with tenantId and simulationId as predicates and an optional agent filter.