Most memory systems borrow one of two metaphors. Knowing which one — and why we picked a third — is the fastest way to understand Geshtu's shape.
Strength: human-readable hierarchy.
Weakness: rigid; cross-cutting queries fight the metaphor.
Best for: solo dev with large personal context.
Strength: simple, fast, well-understood.
Weakness: no team scope, no decision history, no temporal.
Best for: single agent serving many users.
Strength: every query is one SQL filter.
Tradeoff: less "intuitive" than rooms-and-drawers.
Best for: small team handing work off across LLM clients.
Same problem space, different unit of analysis. Geshtu sits in the right-most column because it was designed from the start for shared, async work.
| MemPalace | Mem0 | Zep | Geshtu | |
|---|---|---|---|---|
| Primary unit | Solo dev | User | User + agent | Team + project |
| Memory shape | Spatial hierarchy | Flat stream | Temporal graph | Functional event log |
| Decisions vs facts | Same Hall | One concept | Both as edges | Separate first-class types |
| Async digests | — | — | — | ✓ headline |
| Decision rationale | implicit | — | partial | required field |
| Temporal queries | basic | — | ✓ | ✓ |
| MCP-first | ✓ | partial | ✓ | ✓ |
| Self-host complexity | pip install | Docker | Neo4j+ | one compose |
| Multi-tenant | n/a | yes | yes | no (intentional) |
| License | MIT | Apache | Apache | AGPL-3.0 |
We're not the answer to every "AI memory" question. Here's where each tool wins. Geshtu is the right tool when the primary thing being remembered isn't you — it's the work.
"If a feature request can't be expressed as a query against one of these four tables, treat it as a signal to push back, not as a signal to add a fifth table."— from the spec, on keeping the schema small
Five minutes from clone to running. AGPL-3.0, no signup.