Export and import

Your memory is yours to take with you. meaning-memory export writes everything a deployment holds into a directory of plain JSON Lines files that you can read with jq, load into another system, or import into another Meaning Memory deployment. The same files move memory between backends, so this is also how you go from the file backend to Postgres.

Export

Export reads the store, not the queue. Run consolidation first so that recently written memories are included (see When memories become searchable):

MM_BACKEND=file meaning-memory consolidate --agent-id support-bot --drain-only \
    --workspace /srv/support-bot-mm --config-dir /srv/support-bot-mm

Then, from the file backend:

MM_BACKEND=file meaning-memory export --backend file \
    --workspace /srv/support-bot-mm --agent support-bot --output ./export

Export complete: ./export
  entries: 8
  sig_events: 15
  relationships: 0
  embeddings: 0

From Postgres, pass the connection string instead of a workspace:

meaning-memory export --backend postgres --dsn "$MM_POSTGRES_DSN" \
    --agent support-bot --output ./export

On Postgres the export covers the whole tenant, every agent’s memories, not just the agent named by --agent. Add --tenant-id to choose the tenant in a multi-tenant deployment. Embedding vectors are left out by default because the target can recompute them; add --include-embeddings to keep them.

What the export contains

$ ls ./export
entries.jsonl  manifest.json  relationships.jsonl  sig_events.jsonl

File	One line per
`entries.jsonl`	Memory: its text, type, category, significance, status, scope groups and, for commitments, status, due time and recurrence.
`sig_events.jsonl`	Change to a memory’s significance or status, with who made it and why. This is the memory’s history.
`relationships.jsonl`	Link between two memories.
`embeddings.jsonl`	Embedding vector, when exported with `--include-embeddings`.
`manifest.json`	The export itself: format version, source backend, tenant, counts and the field list for every file.

Every line is a complete JSON object, so ordinary tools work on it:

jq -r 'select(.memory_type == "commitment") | [.commitment_status, .due_at, .text] | @tsv' \
    ./export/entries.jsonl

The manifest lists one table that is never exported: raw conversation transcripts captured for episodic memory. They hold full human conversations, so they do not leave the deployment in a bulk export.

Import

Into another file workspace. Create the workspace first, then import into it:

meaning-memory init --agent-id support-bot --backend file \
    --workspace /srv/restored-mm --non-interactive
meaning-memory import --target file --input ./export \
    --workspace /srv/restored-mm --agent support-bot

Import complete from ./export
  source backend: file
  source tenant:  default
  entries imported: 8
  entries skipped (duplicate): 0

Into Postgres:

meaning-memory import --target postgres --dsn "$MM_POSTGRES_DSN" \
    --input ./export --agent support-bot

The target database must already have the schema: run meaning-memory schema --apply against it first.

Import is safe to repeat. Memories already present are skipped, not duplicated:

  entries imported: 0
  entries skipped (duplicate): 8

Commitments arrive with their state intact: open ones stay open with the same due time, closed ones stay closed, and a recurring duty keeps its rule and where it is in the schedule.

Moving from the file backend to Postgres

Create the database, enable the vector extension (CREATE EXTENSION vector;), and run meaning-memory schema --apply.
Stop the agent, run consolidation, and export from the file workspace, as above.
Import into Postgres with --target postgres.
Point the agent at Postgres: set MM_BACKEND=postgres and MM_POSTGRES_DSN in its MCP configuration, and restart it.

Keep the export directory until you have checked the agent’s memory on the new backend.