Skip to content
Memoturn
Get started
open source · Apache-2.0

Memory for AI agents, in a database built for it.

Memoturn gives every user, team, or agent persona an isolated memory profile all of their agents share — typed memories with supersession, hybrid recall, and a tiny per-profile database you can checkpoint, fork, and rewind. Self-hosted, on any Kubernetes.

License
Apache-2.0
Ingest latency
ingest p50 3.9 ms
Recall latency
recall p50 11.7 ms
Branching
branch in O(1)
speaks
  • MCP
  • TypeScript
  • Python
  • CLI
  • Kubernetes
  • S3-compatible
one memory surface

why memoturn

Agents remember in app code today: a vector store here, a KV cache there, transcripts somewhere else — and nothing forgets correctly.

Agent memory is not a vector store with extra steps. Memoturn moves memory into the database: typed records that supersede instead of duplicate, recall that fuses keyword, topic, and vector signals, and one profile boundary no data ever crosses — in one unit that replicates, branches, and rewinds together.

what you get

A memory database, every layer open.

Typed memories, hybrid recall, and branching aren't an app-side library — they're database semantics you can inspect, self-host, and operate. Open source, top to bottom.

shared

One profile, every agent

Each user, team, or persona gets an isolated memory profile that all of their agents read and write. Isolation is structural — namespace > profile > memory — no data ever crosses a profile boundary, and deleting a profile revokes its stale write tokens.

namespacesprofilesisolation

evolving

Memory that updates without forgetting

Typed memories — facts, events, instructions, tasks — with supersession by topic: a new fact replaces the old one on the same topic and keeps the history. Ingest is idempotent; forget is explicit.

supersessiontopic_keyidempotent

relevant

Recall that ranks, not greps

Hybrid recall fuses full-text, topic, and vector search with reciprocal-rank fusion and channel attribution — and returns empty when nothing matches, instead of guessing.

FTS5vector ANNrank fusion

also in the database

database per profile

Every profile is its own tiny libSQL database — provisioned in microseconds, hibernating to object storage at near-zero cost when idle, holding memories, documents, KV, vectors, and transcripts in one unit.

libSQL17 µs provisiontiering

burner branches

O(1) copy-on-write forks of an agent's whole memory. Checkpoint before a risky run, rewind if it learned garbage, branch a session and let it expire — branching is a manifest write, not a data copy.

checkpointrewindcopy-on-write

multi-model API

Document collections on JSONB, KV namespaces with TTL, vector search, and a SQL escape hatch — one consistency model across all of it, with every read disclosing its `txid`.

docs / KV / SQLvectorstxid

object storage is truth

Committed transactions ship as immutable segments to object storage — opt into durable mode and writes ack only after the segment lands. Nodes are disposable, replicas stream the log, and writer leases with epoch fencing make zombie writers harmless.

segment logetcd leasesepoch fencing

extraction & embeddings, opt-in

Bring your own pipeline by default, or opt in per node: server-side extraction distills raw transcripts into typed memories, and auto-embedding adds the vector channel to bare-text ingest — both outside the write path.

extractionvoyage / openaioff the write path

self-hosted

A Rust data plane and one Helm chart hardened by default — non-root, read-only rootfs, locked-down egress — on any Kubernetes (EKS, GKE, AKS, or your own metal) with any S3-compatible object store. MCP server, CLI, and TypeScript/Python SDKs included.

Helmmulti-cloudMCP + SDKs

what you build

Memory primitives, composed into real agents.

The same profile, supersession, recall, and branching primitives back a range of agents — from personal assistants to multi-tenant fleets — all on infrastructure you own.

01

Assistants that actually remember

Facts and preferences persist across every session and every agent the user touches — and a new fact about their diet supersedes the old one instead of contradicting it.

factssupersessioncross-agent

02

Multi-agent fleets with shared state

Planner, researcher, and executor agents read and write one profile — each contribution attributed, nothing leaking between users, because the boundary is a database file.

shared profileisolationattribution

03

Safe experimentation on live memory

Snapshot an agent's mind before a risky run, let it learn, and rewind or promote — burner branches are O(1), copy-on-write, and auto-expire.

burner branchesrewindPITR

04

Per-session scratch state

Task memories attach to a session and expire on TTL; the verbatim transcript layer keeps every turn searchable until you end the session — no cleanup job.

sessionsTTLtranscripts

05

Tool-native memory over MCP

Agents ingest and recall memory as MCP tools — no SDK in the loop required — with the same namespace tokens and profile boundaries as every other surface.

MCPmemory_recalltokens

06

SaaS agents at tenant scale

Millions of tiny databases on disposable nodes: one per user, near-zero cost idle, single-writer SQL semantics with failover under fifteen seconds.

DB-per-tenanttieringleases

ready when you are

Give your agents memory on infrastructure you own.

Open source, Apache-2.0. Run `memoturnd` for a local node, or one Helm chart on any Kubernetes for production.