Go + PostgreSQL server fork — production-ready, Kubernetes-native backend for MemPalace

[sefodo26]

Hi MemPalace team and community,

First of all, a big thank you to everyone who built this project. The palace metaphor — wings, rooms, drawers — is genuinely elegant, and the benchmarks (96.6% R@5 raw on LongMemEval without any LLM) speak for themselves. It's a pleasure to build on top of this work.

---

What I built

I've implemented a Go + PostgreSQL server for MemPalace:
👉 https://github.com/sefodo26/mempalace-server

This is not a Python port — it's a reimplementation of the MemPalace concept in a different runtime. It keeps the same conceptual model (wings → rooms → drawers, semantic search, knowledge graph, tunnels) and exposes the MCP protocol over HTTP, so any MCP client that works with the original can talk to this server.

---

How it differs from the original design

I'll be upfront: I've repurposed some design decisions, so this is not a 1:1 translation of the Python codebase:

• Storage: ChromaDB is replaced by PostgreSQL + pgvector — all embeddings and semantic search live in Postgres, no separate vector store process.
• Knowledge graph: Uses Apache AGE (a PostgreSQL extension that adds a graph layer) instead of SQLite, giving temporal validity windows directly inside Postgres.
• Embeddings: Works with any OpenAI-compatible embedding API (Ollama, LM Studio, LocalAI, OpenAI, …), defaulting to embeddinggemma (768 dims, 100+ languages).
• Runtime: A single Go binary — fast startup, low memory footprint, no Python dependency.
• Auth: API key on every request, with an optional separate read-only key for dashboards or customer-facing use.

---

Why this stack?

The motivation was a production/enterprise deployment scenario where you want:

• Everything in one database — Postgres handles relational data, vector search (pgvector), and the graph (AGE) in a single connection. No separate processes to operate.
• Kubernetes-native — the repo ships with ready-made K8s manifests (Namespace, PostgreSQL StatefulSet, server Deployment, Service, Ingress, Secret). kubectl apply -f k8s/ and you're done.
• Multi-tenant from the start — a MEMPALACE_TENANT_ID env var keeps data fully separated, so one server instance serves multiple users or projects.
• Operational simplicity — standard Postgres backup/monitoring tooling applies; no exotic dependencies to learn.
• Low latency — Go's small memory footprint and fast startup suit a memory server that sits on the critical path of every AI agent response.

---

Claude Code skills included

The repo also ships three Claude Code skills for working with the server directly from within Claude:

• mempalace-ingest-docs — file documents into the palace
• mempalace-read-docs — search and export memories
• mempalace-zettelkasten — capture atomic, linked notes

---

My question to the community

I'm fairly new to the MemPalace protocol internals and would love feedback:

1. MCP protocol conformance — did I implement the MCP tools correctly? I modeled them after the original's tool list but may have missed nuances in schema or behavior.
2. Palace structure fidelity — does my wings/rooms/drawers model map correctly to what the original intends? I'm worried I may have flattened some nuances.
3. pgvector vs ChromaDB — any known gotchas with this swap at scale (HNSW tuning, ef_search, index maintenance)?
4. General feedback — "this is not how MemPalace should work" is equally welcome.

Happy to discuss any of it. Thanks again for building something worth forking! 🙏

— Hans-Martin / @sefodo26

[richardchen874-sys]

This is a very interesting direction.

What I like here is that you are treating memory as production infrastructure, not only as a local experiment. Moving embeddings, semantic search, graph state, tenant isolation, auth, and MCP access into a Go + PostgreSQL backend makes sense for agent systems that need to run reliably outside a single-user desktop setup.

The pgvector swap is especially interesting. I think the main things to watch at scale are not only retrieval quality, but operational behavior:

• HNSW index build and maintenance time
• ef_search tuning by latency vs recall target
• embedding dimension consistency across providers
• tenant-level isolation in vector queries
• query latency under concurrent MCP clients
• backup / restore behavior when vectors and graph state live together
• whether temporal graph validity affects retrieval ranking
• how stale or duplicated memories are compacted over time

The OpenAI-compatible embedding API support is also useful. For memory systems, provider compatibility matters because embeddings can become a long-term storage decision. If teams change embedding providers later, they need to know whether they can re-index safely, compare recall quality, and avoid mixing incompatible vector spaces.

For agent memory, I think the key metric is not only raw R@5, but useful recall per workflow:

• did the agent retrieve the right memory at the right time?
• did it reduce repeated context injection?
• did it lower token usage in long sessions?
• did it avoid stale or misleading memories?
• did latency stay low enough to sit on the critical path?

This fork seems like a strong step toward a Kubernetes-native memory layer for MCP-based agents.

[richardchen874-sys]

Thanks for the detailed explanation — I really like that you’re already thinking beyond a local memory toy and toward a more managed, multi-agent memory layer.

The centrally managed shared memory idea is especially interesting. If multiple agents can reuse memory instances safely, even in a read-only way, that starts to look much closer to real agent infrastructure than just another local notes/vector-store wrapper.

On the benchmark side, I agree it is probably hard to judge from one layer alone. A Go server may improve part of the path, but the real question is probably end-to-end performance:

• how fast a memory lookup becomes a useful agent answer
• whether recall quality improves across repeated sessions
• whether the LLM/card-index preprocessing actually reduces long-context token usage enough to justify its cost

For the LLM preprocessing part, I’d probably test embeddings and generated memory cards separately by provider/model first, before mixing everything together. Otherwise it becomes hard to know whether a recall issue comes from the memory design, the embedding space, or the preprocessing model.

I’ve been looking at multi-model API routing, embedding compatibility, and cost/latency trade-offs in agent workflows recently, so your current direction is very relevant to what I’m working on. If useful, I’d be happy to help you think through a small benchmark setup based on your current design — especially around provider comparison, embedding behavior, and cost per useful memory recall.

[sefodo26]

I ran a few benchmarks locally using Minikube to make the results comparable, since network latency plays a major role in a server setup.

In terms of performance, it seems to be slightly better, but that could also be due to the hardware used and the embedding model.

https://github.com/sefodo26/mempalace-server/tree/main/benchmark

Best regards,

SeFoDo

[richardchen874-sys]

@sefodo26 Thanks for sharing the benchmark — this is actually more useful than a simple “Go server ops/sec” test.

What I like is that you are measuring the end-to-end memory path: lookup → useful answer, recall across sessions, and card-index vs long context. That fits your German law use case much better than a pure server benchmark, because the commercial question is not only whether retrieval is fast, but whether the memory layer saves enough repeated context and improves recall enough to justify the preprocessing.

The results are interesting too: retrieval seems to be a relatively small part of the wall-clock time, while generation dominates. So optimizing only the Go/Postgres layer may not move the full system cost as much as optimizing the embedding/card-index pipeline and the model used after retrieval.

For your original German law MCP idea, I think the next benchmark layer would be:

• preprocessing cost per legal document / judgment / statute section
• embedding time and cost by model
• card generation cost if an LLM is used before embedding
• token saved per future query
• break-even query count per legal memory set
• recall quality on “colloquial German → legal German” queries
• recall quality on doctrinal links that embeddings alone may miss

That would separate the engineering question from the business question: the system may work technically, but the commercial blocker is whether the one-time preprocessing cost can be amortized across enough future queries or users.

Your current benchmark already shows the shape of the value. I’d be curious: when the investor lost interest, was the cost problem mainly the one-time corpus preprocessing cost, or was it uncertainty around whether enough customers would reuse the same German law memory MCP to make that preprocessing cost worthwhile?

[sefodo26]

The problem wasn't so much the one-time preprocessing cost, but rather a fundamental misunderstanding on the other side. The potential partner was a small law firm, and their argument boiled down to: "Why should we pay for local LLM inference when ChatGPT can do it for free?"
A single benchmark run cost about €150 on Anthropic — which is perfectly reasonable for a development phase, but for a small firm that doesn't see the difference between a generic chatbot and a specialized retrieval pipeline, any amount sounds "too expensive" as long as the free alternative exists.
So the real problem wasn't technical or financial, but a communication problem: the added value of a domain-specific memory system over a generic LLM is hard to grasp for non-technical people — especially if they've never experienced where ChatGPT hallucinates on legal questions or misses relevant doctrinal connections. The firm was essentially comparing apples to oranges, but as long as "free and good enough" is on the table, it's a tough pitch.
That's ultimately what led me to shift focus more toward the technical side and build out the infrastructure properly first, rather than continuing to try to convince someone of a problem they don't perceive as one.

[richardchen874-sys]

That makes sense — it sounds like the real blocker was not the €150 benchmark cost, but the customer’s mental model of what they were buying.

For a small law firm, “local LLM inference” probably sounds like a more expensive version of ChatGPT. But the value is actually different: controlled legal memory, reusable domain-specific context, citation discipline, and reducing the risk of missing important doctrinal links over repeated work.

I think the strongest demo would be very concrete and non-technical:

Take one real legal question from their workflow, run it through free ChatGPT, then run the same question through the domain-specific memory pipeline. Instead of explaining architecture, compare:

• whether the answer cites the right source
• whether legally important wording is preserved
• whether relevant prior context is recalled
• whether the system can explain where the answer came from
• whether repeated queries become cheaper or more consistent over time

That reframes the product from “paid LLM inference” to “a reusable legal memory layer for the firm’s own knowledge.”

I’ve been thinking about this a lot from the API/provider side too. For production AI workflows, cost is not just price per call — it is whether the model/provider setup can reliably produce grounded answers with predictable latency and traceable metadata. In legal use cases, that traceability may be more valuable than raw model intelligence.

[jphein]

Hans-Martin — this is great work, and your architecture bet is more validated than you might realize: you, our fork (techempower-org/mempalace, production since May), and upstream's own new pgvector backend all independently converged on Postgres + pgvector (+ AGE for the graph). Three parties, same substrate. We run 411K drawers on it daily, so your questions land squarely in our scar tissue — answers below, plus findings from actually running your server this week.

Q3 — pgvector vs ChromaDB at scale (our production experience)

• The latency bottleneck probably isn't where you think. We measured our stack end-to-end: warm search costs ~650–900ms and it's dominated by query-embedding inference, not pgvector — ANN over 411K rows is fast. This matters doubly for your design since you embed via an external OpenAI-compatible API (network + inference per query). A query-embedding LRU cache is worth more than any Go-level optimization; our own write-up: discussion #1659 — "where the bottleneck actually is".
• Index health decays silently. One of our production wings' HNSW indexes degraded to serving 2 vector results with the rest falling back to keyword-only — recall silently capped, no error anywhere. Monitor index health (result-count sanity probes), don't just create indexes.
• Statement timeouts everywhere. Our SQL fast paths wrap in SET LOCAL statement_timeout = '3s' so one stuck query can't wedge a status endpoint. Cheap insurance you'll want before multi-tenant load.
• Status via SQL aggregates. Wing/room counts by GROUP BY instead of client-side metadata sweeps took us ~29s → <100ms at 370K rows. You already do this — keep it as the palace grows.

Q1 — MCP conformance

Tool count is a moving target (upstream sits at 35 today; we carry 39; you expose 37) — so conformance is really about contract shapes, not the list. One trap we hit that a reimplementer can walk into: Anthropic's API rejects tool schemas with a top-level anyOf/oneOf and silently drops the whole tools array; upstream enforces either-field requirements at dispatch instead of in the schema. Worth auditing your schemas against that.

Q2 — structure fidelity

One nuance that's easy to flatten: room taxonomies fragment silently unless validated — free-form room names decay into near-duplicates. We ship a canonical room taxonomy with soft-warn validation for exactly this reason. And since you're the only other AGE-backed palace graph we know of: our temporal-validity work (SPOC context slots) is in flight — happy to compare modeling notes.

We actually ran your server — findings

We forked it for evaluation, stood it up on Linux, and wrote an adapter for our multipass structural eval harness (merged; your server is now benchable alongside MemPalace, OMEGA, engram, and the rest of the cohort — cross-system results render on our public results site). Along the way:

1. Linux bug in your default compose: host.docker.internal doesn't resolve on native Linux Docker, so the documented Ollama setup fails for every Linux user. Three-line fix — add to the app service:

   extra_hosts:
     - "host.docker.internal:host-gateway"

2. Two undocumented behaviors integrators need to know (both fine, both surprising): drawer IDs are deterministic (sha256(wing/room/content-prefix)) so re-adding returns already_exists — great idempotency, but callers must handle it; and content that is a pure bullet list gets split into N drawers with a bullets_stored response shape instead of a drawer_id. Both deserve a README note.
3. Your KG is storage-only — add_drawer never populates the AGE graph; only explicit kg_add_* does (we verified in source and live). If that's intentional, it's a legitimate design point (extraction belongs to the client) — but worth stating explicitly, since MemPalace-family users may expect graph auto-population, and upstream just shipped exactly that (feat(graph): auto-populate the associative graph from mined sessions #1895).
4. No LICENSE file — this is the one blocking issue for the enterprise audience you're targeting: unlicensed code is unadoptable by policy at most orgs. An SPDX one-liner would change what people can do with this.

Happy to share more operational detail (HNSW params at scale, migration tooling, our daemon's single-writer rationale) — and if you're interested, we'd gladly run your server through the full eval matrix as it evolves. Welcome to the substrate club. 🐘

[sefodo26]

---

Wow — first of all, a huge thank you for this incredibly detailed and valuable post. The fact that you took the time not just to read the code but to actually stand up the server, run it through its paces, and integrate it into your eval harness goes far beyond what I expected. This is open-source spirit at its finest.

On the specific points:

I've implemented most of your suggestions. The Linux fix for host.docker.internal is in, the undocumented behaviors (deterministic drawer IDs and bullet splitting) are now documented in the README, and — perhaps most importantly — the project is now under an MIT license. You're absolutely right: without a LICENSE file, the code is simply unusable for most organizations, no matter how good it is technically. Should have done that sooner.

On the Knowledge Graph, you hit a sore spot — I had indeed neglected that a bit. My original thinking was that graph population should intentionally live on the client side, but I see that for many users this is an unexpected gap. My solution: I now explicitly let the operator choose whether and how the KG gets populated. Concretely, there are three modes — fully disabled, static extraction on write (rule-based, no external dependencies), or LLM-powered extraction that automatically extracts entities and relations from the content and writes them into the AGE graph when a drawer is created. This way everyone can decide for themselves where the trade-off between autonomy, cost, and graph quality should sit.

On the question of room taxonomy fragmentation, I have to be honest: I don't have a truly satisfying answer yet. The fundamental problem is that when creating rooms you'd essentially need a crystal ball to choose accurate, long-lived names from the start — and in practice, a knowledge base grows organically, not according to plan. Your approach with a canonical taxonomy and soft-warn validation is clever, but it assumes you know the domain well enough upfront. What appeals to me more is the reverse approach: a retrospective merge. Tooling that detects near-duplicates after the fact — via embedding similarity of room contents or name fuzzy matching, for example — and suggests a merge to the user. That fits better with a system that co-evolves with its user rather than requiring a rigid structure upfront. Still in the idea stage though, not in code.

The notes on HNSW index degradation and statement timeouts I'm taking especially to heart — exactly the kind of production experience you can't just read about. Your discussion thread #1659 on embedding latency was eye-opening; a query embedding cache is now on my roadmap.

Speaking of the eval harness: the fact that my server is now part of your benchmark cohort alongside MemPalace, OMEGA, and engram is fantastic — and I'd be very curious to see the results. The direct comparison on the same substrate (Postgres + pgvector + AGE) in particular should be revealing, because architectural decisions above the storage layer become so much more visible that way. If you share the results, I'll gladly take any feedback — including the uncomfortable kind.

On SPOC and temporal validity: I'd love to exchange notes. Similar modeling questions have been on my mind as well, and having a second AGE-backed palace to compare against is a rare opportunity.

Thanks again — and yes, glad to be part of the Substrate Club.

[sefodo26]

Regarding Q2 — I've been giving the room taxonomy fragmentation problem more thought since my initial response. Rather than trying to get names right upfront (crystal ball not included), I've been exploring the opposite direction: retroactive reconciliation. This branch might be of interest: feat/room-redirects. The idea is to introduce room redirect mappings so that when near-duplicates are identified — whether through embedding similarity, fuzzy matching, or manual review — rooms can be merged without breaking existing references. Fair warning: this is very much experimental and untested at this point, so treat it as a proof of concept rather than something production-ready. But the general direction feels right to me — let the palace grow organically with its user and reconcile afterward, rather than demanding a rigid taxonomy from the start. Feedback and battle scars welcome.

[jphein]

Hans-Martin — same-day MIT license, Linux fix, and documented behaviors? That's the fastest maintainer turnaround we've seen in this ecosystem. Two things back:

Your server is now on our public results board: the SME field explorer — look for MemPalace Server (Go, sefodo26). The published column carries your methodology-matched R@5 0.972 (linked to your COMPARISON.md); the SME columns carry our 2026-07-04 structural readings with committed baseline artifacts. One honesty note on how we scored it: since your KG fills only via explicit kg_add, the emergent-structure cells read basis=taxonomy — recorded as a design difference (storage-only KG vs OMEGA's auto-relate vs our fork's write-through LLM extraction), not a defect. If anything in the row misrepresents your design, say so and we'll fix it.

On feat/room-redirects: retroactive reconciliation matches what we actually observe in production — taxonomies drift no matter what you do upfront; our soft-warn validator only slows the bleeding. Redirect mappings as the repair path composes nicely with that (warn early, merge late, never break references). We'll watch the branch — and if it stabilizes, a "room drift + repair" reading would make a good addition to the eval's ingestion-integrity category.

Your law-firm story rings very true from our side of the fence (we're a nonprofit that serves orgs with exactly that "why not just ChatGPT" gap). The only thing we've seen work is a side-by-side on their documents — generic model hallucinating a citation vs the retrieval pipeline quoting the source verbatim. Abstract arguments about architecture never land; one wrong legal citation in front of a lawyer does.