RushDB: Agent Memory Zonder Schema — Maar Ook Zonder Governance

Er is een hardnekkige misvatting in de agentic AI-wereld. De misvatting dat "geen schema nodig" hetzelfde is als "geen datamodel nodig." RushDB is het perfecte voorbeeld van waarom die misvatting gevaarlijk is.

RushDB is een graph database-platform bovenop Neo4j. Je pusht JSON. De server parsed veldtypes, bouwt automatisch een graph-structuur, indexeert vectors, en stelt alles beschikbaar via één API. Geen Redis. Geen losse vector-DB. Geen sync-code tussen systemen. Geen migraties.

Het klinkt als de heilige graal voor AI-agent-geheugen. En technisch is het indrukwekkend. Maar onder de motorkap schuilt een fundamentele spanning tussen ontwikkelsnelheid en governance, een spanning die elke CISO zou moeten herkennen.

Wat RushDB technisch anders maakt

De kerninnovatie van RushDB is het Labeled Meta Property Graph-model (LMPG). In plaats van JSON op te slaan als platte documenten, decomposeert RushDB het in graph-elementen. Een nested object wordt automatisch:

• Opgesplitst in records met labels
• Verbonden via relaties
• Verrijkt met type-informatie
• Beschikbaar gemaakt voor introspectie

Een agent kan via de ontology-API ontdekken welke labels, properties, typen en relaties er bestaan, vóórdat hij een query formuleert. Dat is architectonisch sterker dan een agent die Cypher of SQL hallucineert op basis van een prompt.

Het querymodel is ook doordacht. Eén SearchQuery combineert scalar filtering, ranges, boolean logic, graph traversal en vector similarity. Voorbeeld:

{
  "labels": ["MEMORY"],
  "where": {
    "agent_id": "agent-42",
    "validated": true,
    "STRATEGY": { "name": "worker-capability-routing" }
  },
  "limit": 10
}

Dit is een gesloten, valideerbaar query-oppervlak, kleiner dan raw Cypher, eenvoudiger te whitelisten, beter geschikt voor tool contracts.

Waar de marketing te ver gaat

De slogan is: "No forced memory schema. Send nested JSON as often as your workflow produces it."

Dat is waar. Maar het is niet het hele verhaal.

RushDB elimineert migrations. Het elimineert niet de noodzaak van betekenis, datakwaliteit of governance. Het verplaatst schemawerk van vooraf ontwerpen naar runtime observeren. Dat is schema-on-read met graph-intelligentie, geen governance-vrije dataopslag.

In een enterprise-omgeving ontstaat zonder actieve governance snel:

• customer, Customer, CLIENT en client, vier labels voor hetzelfde concept
• status met verschillende definities per record
• Properties die van type veranderen zonder dat iemand het merkt
• Relaties zonder business-betekenis
• Onbeheerste groei van labels en properties

Dit is precies het patroon dat de NSA signaleerde in haar MCP-security analyse: tools die persistent schrijven zonder eigen autorisatielaag creëren nieuwe aanvalspaden. RushDB's MCP-server vertrouwt erop dat de client juiste inputs stuurt, er is geen message signing, geen tool-level policy, geen capability enforcement.

Het echte risico: memory poisoning

De combinatie MCP + RushDB + agent-tools creëert een risico dat verder gaat dan SQL injection of path traversal. Het is memory poisoning: een agent schrijft door prompt-injection verontreinigde data naar het gedeelde geheugen, mét graph-links en embeddings. De volgende agent leest die data in en baseert beslissingen op gemanipuleerde context.

Dit is fundamenteel anders dan een database-injectie. Een SQL-injectie lekt data. Memory poisoning beïnvloedt toekomstige beslissingen van andere agents.

De oplossing is niet "vertrouw de agent." De oplossing is een memory lifecycle:

candidate → validated → approved → active → deprecated → revoked

Alleen een expliciete validator, een mens of een governance-agent, mag memory promoveren van candidate naar validated. Alles wat een agent schrijft, begint als kandidaat. Alles wat een agent leest, is minimaal validated.

Dit sluit aan bij Microsofts agent governance-model: "Behandel agents als werknemers, met identiteiten, permissies en audits." Een werknemer mag voorstellen doen. Een werknemer mag niet zijn eigen voorstellen autoriseren.

Wat RushDB wél goed doet

RushDB onderscheidt drie geheugenlagen, een conceptueel model dat beter is dan de meeste agent-frameworks:

Laag	Functie	Mechanisme
Episodisch	Gebeurtenissen, acties, observaties	Records en relationships
Semantisch	Betekenis en overeenkomst	Embeddings en vector properties
Structureel	Kennis over eigen datastructuur	Ontology API

Een agent die een taak uitvoert, kan:

1. Via de ontology-API ontdekken wat er al bestaat
2. Episodische records opvragen over vergelijkbare taken
3. Semantisch zoeken naar relevante patronen
4. Zijn resultaten terugschrijven met provenance-metadata

Deze gelaagde retrieval, structureel filteren, dan semantisch herordenen, is architectonisch zuiverder dan de gangbare praktijk van "dump alles in een vectorstore en hoop dat de embedding het snapt."

De Neo4j-olifant in de kamer

RushDB is geen onafhankelijke database-engine. Het is een platformlaag bovenop Neo4j. De prestaties, schaalbaarheid, backup-strategie en failure modes worden grotendeels door Neo4j bepaald.

Dat heeft consequenties. Neo4j Enterprise, nodig voor clustering, hot backups en fijnmazige RBAC, kost al snel €200.000 per jaar. De RushDB self-hosting docs gaan uit van Neo4j Community Edition, die single-node is en geen clustering ondersteunt. Voor productie bij gereguleerde organisaties is dat een non-starter.

Daarnaast: raw Cypher is beschikbaar wanneer RushDB aan een eigen Neo4j-instance is gekoppeld. Dat is krachtig voor geavanceerde scenario's, maar mag nooit rechtstreeks aan een generieke agent worden blootgesteld. Onbegrensde traversals, data-exfiltratie, massamutaties, de aanvalsoppervlakte van raw Cypher is een orde groter dan die van SearchQuery.

Operationele volwassenheid

De GitHub-repository toont actieve ontwikkeling: 838 commits, 128 tags, release v2.2.1 van gisteren. De documentatie is helder. De MCP-server werkt met Claude Desktop, Cursor, en VS Code.

Maar:

• 171 stars, 11 forks, geen brede externe validatie
• Eén zichtbare maintainer ("1pxone"), busfactor 1
• Geen SOC 2, ISO 27001, of AVG-verwerkingsregister
• Geen EU-hosting voor de cloud-tier
• Elastic License 2.0 op het platform (niet OSI-goedgekeurd)

De licentie is een nuance die ertoe doet. SDK's en MCP-server zijn Apache 2.0, permissive open source. Het platform en dashboard zijn Elastic License 2.0, broninzage, geen vrije herdistributie. Voor embedded use of managed service-providers kan dat beperkend zijn.

RushDB vs. de alternatieven

Oplossing	Sterkste punt	Zwakste vs. RushDB
Neo4j direct	Maximale controle, volwassen ecosysteem	Meer schema- en applicatiewerk
PostgreSQL + pgvector	Volwassen, governable	Graph traversal minder natuurlijk
Qdrant	Sterke vector search	Geen volwaardige graph memory
Redis	Lage latency, ephemeral state	Zwak voor rijke relaties
Mem0	Eenvoudige memory abstraction	Minder rijke structurele queries
Zep	Conversation/agent memory	Minder algemeen databaseplatform
RushDB	Graph + vector + ontology via één API	Jonger, Neo4j-afhankelijk

RushDB concurreert niet primair met Neo4j of Qdrant. Het concurreert met de integratielaag die teams anders zelf bouwen tussen applicatiestate, vector retrieval, graph relations, en ontology discovery. Daar zit de werkelijke waarde.

De juiste architectuur

RushDB zou niet je enige opslaglaag moeten zijn. Het is een knowledge projection, een afgeleide kennislaag, niet het system of record. De juiste architectuur scheidt:

Immutable evidence store (filesystem / object storage)
        ↓
Event & operational store (PostgreSQL / event log)
        ↓
RushDB knowledge projection (graph + vector + ontology)
        ↓
Read-only retrieval tools (agents, planners, evaluators)

Deze gelaagdheid voorkomt dat graph-normalisatie bewijs verandert, dat embedding-poisoning de audit trail aantast, en dat een RushDB-upgrade de reproduceerbaarheid van historische beslissingen ondermijnt.

Agents krijgen standaard alleen SearchQuery-toegang, bounded reads, geen raw Cypher. Writes gaan altijd als candidate met provenance:

{
  "status": "candidate",
  "validated": false,
  "author_type": "agent",
  "confidence": 0.71,
  "source_evidence": ["task-episode-42", "validation-run-7"],
  "retention_class": "temporary"
}

Alleen een governance-agent of menselijke validator mag promoveren naar validated.

Scorekaart

Dimensie	Score
Conceptuele architectuur	8/10
Developer experience	8/10
Agent-memory fit	8/10
Query-expressiviteit	8/10
Enterprise governance	5/10
Security maturity	5/10
Operationele volwassenheid	5/10
Ecosysteem en marktvalidatie	4/10
Geschiktheid voor gecontroleerde pilot	8/10
Geschiktheid als enterprise kernplatform	5/10

Conclusie

RushDB is technisch interessanter dan de marketingterm "instant database" suggereert. De combinatie van graph-relaties, vector search en live ontology discovery adresseert een reëel probleem: agents hebben niet alleen semantische chunks nodig, maar ook structuur, verbanden en kennis over het beschikbare datamodel.

De belangrijkste sterkte is niet "geen schema", maar: een agent kan zichzelf via één gecontroleerde querylaag oriënteren in een evoluerende graph.

De belangrijkste zwakte is eveneens "geen schema": zonder expliciete governance verandert flexibiliteit in semantische vervuiling, memory poisoning en onbeheerste graph-groei.

Gebruik RushDB als afgeleide kennisprojectie, niet als primaire bron van waarheid. Geef agents bounded SearchQuery-toegang, geen raw Cypher. En onthoud de kernles die deze week als een rode draad door alle analyses loopt: een tool zonder autorisatielaag is een incident dat wacht om te gebeuren, of het nou MCP is, een agent-shell, of een graph-database.

---

Dit artikel is gebaseerd op analyse van RushDB v2.2.1 (github.com/rush-db/rushdb) en de documentatie op docs.rushdb.com. Lees ook onze analyses van de NSA over MCP-security, Microsofts agent governance-model, en Odysseus' governance-vacuüm, samen vormen deze vier artikelen een architectonisch raamwerk voor verantwoorde agentic AI.