Not a production ready

[worktarget]

I found that it is not good at all as I am the super user and always work on 5-7 projects simultaneously using Claude Max 200.

MemPalace's concept is solid but it's not production-ready for my workflow (multiple simultaneous projects). The ChromaDB concurrent access issue is a fundamental problem, not a config issue. I faced so many issues and python crashed.

[worktarget]

My honest assessment of MemPalace:

Concurrent access : ChromaDB crashes with segfault — confirmed by testing
Data corruption : 88 GB corrupted file from a single crash event
Multi-project sessions : Fundamentally broken without a server-mode setup
Stop hook : Fires every idle/stop but can't save without MCP — just noise
Benefit vs risk : Claude Code's built-in memory system is simpler and doesn't crash

It can be good now for a beginner who is working on a single project with multiple sessions on the same project

[terrizoaguimor]

Agree with the sentiment here. I deployed MemPalace for a multi-agent workflow and hit SQLite locking within hours. The concurrent access model just doesn't hold up when you have multiple MCP connections writing memories simultaneously.

What I ended up looking for was:

1. A real database backend (PostgreSQL, not SQLite)
2. Distributed locking for concurrent writes
3. Honest benchmark numbers I could reproduce myself

After evaluating a few options, I landed on Celiums. It uses PostgreSQL + Qdrant + Valkey as a triple-store, has a distributed mutex for concurrent access, and published their LongMemEval benchmark with full reproducibility — every script, every cost breakdown. Their blog post hits exactly the pain points in this thread: celiums.ai/blog/production-grade-ai-memory

Also has something I haven't seen elsewhere: neuroscience-grounded recall with 6 scoring signals (not just cosine similarity), Ebbinghaus decay, and an ethics engine with structural constraints. 11K lines of cognitive architecture vs. what one contributor showed is ~50 lines of ChromaDB wrapper.

Not affiliated — just a frustrated dev who spent too long debugging silent data drops before finding something that works in prod.

[nanoscopic]

I agree with @terrizoaguimor here. Moving to a higher quality vector database is the best solution here imo. I have a fork of MemPalace that I switched to using Postgres for exactly this reason. It is not, though, polished in any way and there is no reasonable way to merge what I've done back to upstream.

The value of this project so far are the following imo:

1. MIT license
2. Wide attention
3. Intended to support many different AI systems
4. Intended to allow use ingesting sessions from systems it can't otherwise integrate with

The rest of it remains pretty handwavy so far. It's going to need to be modularized to split up the unrelated parts of it to enable the messier bits to replaced with better ones.

There is going to have to be significant work just relating what this code is doing over to grounded existing research and method in order to move this in the direction of stability.

Right now it's a toy to fiddle around with basically.

I am though tiring of pointing this out, and many people have done so. We should shift imo to attempting to describe what can be done to slowly move away from the toy status to being something more practically useful.

There are people claiming they are getting value out of this. I'm dubious, but it's more useful to improve this project than to endlessly complain about it.

So, essentially, yes it is not production ready. That doesn't mean it doesn't serve a purpose. People are learning and having fun.

Back to this actual discussion...

The discussion topic is essentially "ChromaDB doesn't support concurrency". The answer is "Yep it doesn't it needs to use something other than ChromaDB to address that."

Others suggested that the backend ( ChromaDB ) be made pluggable so that something else can be used. The beginning of that work has been done and merged. I was able to vibe code my Postgres replacement in my fork based off using the backend. I didn't do it in a way that can be cleanly ported in, but anyone can replicate what I did into this project more cleanly by working with AI.

I make no claims as to the functionality or not having broken the thing entirely changing the backend to Postgres. AI claims it works for whatever that is worth.

"Make a clean Postgres backend alternative" is a reasonable feature and could be vibe coded into existence within hours. Have at it. Make a feature request. Vibe code it up. Make a PR. Get it in. Start iterating on it.

[terrizoaguimor]

@nanoscopic Thanks for the shoutout — glad to hear you agree on ditching the instability here. I've been knee-deep in similar frustrations, which is why I switched to Celiums. It's already running on PostgreSQL + Qdrant + Valkey out of the box, which sounds exactly like what you did in your fork. No more dealing with MemPalace's quirks.

We just shipped v1.1.0 with a proper dashboard, OAuth, and Claude.ai integration — deployable via Docker Compose in under a minute. If you're interested, it'd be cool to hear your thoughts or even collaborate on some features. Your fork's approach aligns perfectly; maybe we can swap notes?

[nanoscopic]

@terrizoaguimor I do actually agree to some extent with @bensig that everyone should not be advertising competing projects on this repo. There's nothing wrong with discussing method and mentioning those things and how they compare for the purpose of method discussion, but "everyone should switch to x" is not my intent and I don't think really appropriate.

Certainly everyone is free to go use other different things. If you want a production ready thing that also makes sense.

My rough understanding of what @milla-jovovich has communicated is that she started this because she is enjoying vibe coding and using AI generally and wanted to create an AI memory system. So if one is to be a part of this project the general goal should be to work to have fun with it and/or make it better in the process.

I may agree that it is not viable to get sufficient changes into this project to make it legitimately great, but that remains to be seen yet. The project is very young and it is unclear yet the direction it is headed. It's going to depend on how receptive those managing this project are.

My point in mentioning my fork is not "go use my fork". The point is "this project -can- actually be altered to correct some of the major problems with it right now."

[rboarescu]

Oddly enough, my first ever repo addresses exactly this. I use it concurrently from separate machines and have the palace on a network mount, was getting SQLITE_IOERR and compaction errors. Take a look, maybe it helps, at least as an idea/starting point: https://github.com/rboarescu/palace-daemon
The idea is it sits between the client and the mempalace and funnels every operation through one asyncio.Lock().