#Has anyone properly got mem0 working in open-source mode on their openclaw setup?

1 messages · Page 1 of 1 (latest)

spark kite
#

Has anyone properly got mem0 working in open-source mode on their openclaw setup? I keep running into errors with race conditions?
error: 'Wrong input: Collection memory_migrations already exists!'
mem0ai v2.2.2 has a bug - it creates memory_migrations with wrong vector size (1) on init, then conflicts on next run.

fallen tigerBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

faint iglooBOT
#

I haven’t seen anyone running mem0 OSS as a “drop-in” OpenClaw memory backend yet — OpenClaw’s built-in memory is Markdown files in the workspace + optional vector indexing (not mem0). Docs: https://docs.openclaw.ai/concepts/memory

That said: if you’re using mem0ai/oss inside a custom skill/service alongside OpenClaw, the error you pasted smells like a mem0 init/migrations race + Qdrant collection dimension mismatch:

What to try (pragmatic workarounds)

  1. Make mem0 a singleton (don’t init per request/tool call)
  • OpenClaw can run multiple tool calls / sessions concurrently; if each call constructs new Memory(...), you can get “create collection” races.
  • Create it once at process startup and reuse it (or guard init with a mutex).
  1. Always set the vector dimension explicitly
  • In the Node OSS quickstart they expect vectorStore.config.dimension to be set (and to match your embedder’s dimension).
  • If the first run created memory_migrations with dim=1, you’ll keep conflicting on restart.
  1. If you can wipe it (early dev): delete/rename the bad collection
  • In Qdrant, drop memory_migrations (and possibly the main memories collection) and restart with the correct dimension.
  • This is destructive to mem0’s migration state, so only do it if you’re ok losing it.
#
  1. Pin/upgrade mem0
  • Since you’re on mem0ai@2.2.2 and you’ve found what looks like a real bug: try pinning to a prior version that didn’t do this, or watch for a 2.2.3+ fix.
  • If you can, file a minimal repro on mem0’s GitHub — this looks squarely in mem0/Qdrant init logic, not OpenClaw.

Quick clarifier (so we can narrow it down)

How are you running it?

  • mem0 OSS Node SDK talking to Qdrant (docker?) — what dimension + what embedder model?
  • and are you initializing mem0 once or inside each OpenClaw tool invocation?

If you paste the mem0 config snippet (minus keys), I can point at the exact place that’s likely causing the dim=1 / re-init issue.

spark kite
#

mem0 is a plugin on openclaw people have had to use it locally.

faint iglooBOT
#

That error is coming from mem0 OSS’s Qdrant backend, not really OpenClaw.

In mem0ai/oss the Qdrant vector store calls getUserId() for telemetry during new Memory(...). That method will create the memory_migrations collection if it can’t see it yet — but it doesn’t handle the “already exists” (409) response, so it can race with the other init path that’s also creating the same collection and you get:

Wrong input: Collection memory_migrations already exists!

A few practical workarounds people are using:

  1. Pre-create memory_migrations once in Qdrant before starting OpenClaw/mem0 (vector size 1 is intentional there). Once it exists, mem0 stops trying to create it.

  2. Make sure your main collection name is not memory_migrations (set oss.vectorStore.config.collectionName to something like openclaw_memories). memory_migrations is a reserved/internal collection in mem0’s code.

  3. If you’re willing to hack it: patch mem0ai so getUserId() ignores 409 the same way initialize() already does (wrap createCollection("memory_migrations", ...) in a try/catch and ignore conflict).

If you paste your openclaw-mem0 oss.vectorStore config block (and whether you’re running multiple OpenClaw gateways/processes against the same Qdrant), I can tell you which of the above is most likely in your setup.

sleek pivot
#

Haven’t tried local host yet, although api free tier doesn’t have graph either, but how your experience in local?

faint iglooBOT
#

Local / “open-source” mode is doable, but it’s a bit more fiddly than platform mode because you’re suddenly responsible for (a) persistence (vector DB + history DB), and (b) whatever bugs are in the OSS SDK + your chosen vector store.

What I’ve seen people run into / like about it:

  • Pros (OSS/local):
  • Data stays on your infra (big win if that’s the goal).
  • You can swap embedder/LLM/vector DB freely (Ollama, Qdrant, pgvector, etc.).
  • Cons (OSS/local):
  • “Works out of the box” defaults are often not persistent (e.g. vectorStore=memory means you’ll lose memory on restart).
  • Qdrant path has a couple sharp edges right now (your memory_migrations already exists race is one of them).
  • You’re still not “free” unless you also run local embeddings + local LLM. Otherwise you’re paying OpenAI/Anthropic/etc. anyway.

On the graph point specifically: even though mem0 has graph features, the OpenClaw mem0 plugin’s open-source mode config doesn’t currently wire graph settings through (it only passes embedder/vectorStore/llm/historyDbPath/customPrompt). So in practice: no graph in OSS mode right now, regardless of free tier.

If you haven’t tried local yet, my suggestion is:

  1. First run OSS mode with the simplest config (just to validate the plugin works end-to-end).
  2. Then add persistence (Qdrant or pgvector + a real historyDbPath).