pumaDB

pumaDB's pitch is narrow and honest: agents forget, pumaDB remembers. The homepage example is the clearest statement of the product—ChatGPT logs a checkout bug's root cause into a bugs table, and a fresh Claude chat with no pasted history recalls it. That works because both clients point at the same MCP endpoint (api.pumadb.ai/mcp) and the same tables, so the handoff costs nothing. The second capability that matters is dual access: 'one memory surface, two ways in.' MCP is for agents you authorize; REST is for code you trust, against the same rows and same limits. That means a cron job, a worker, or a CLI script can seed or read the same memory your chat client uses, which is the gap most single-interface memory tools leave open. The records pumaDB is designed for are deliberately small—agent instructions, project conventions, user preferences, research clippings, task state, and reviewed technical references. It stores them as schema-less JSON rows and tags each with id, created_at, and updated_at, with last 10 versions per row retained 30 days and row-level restore. For agent work, version history is the underrated feature: when an agent overwrites a preference with nonsense, you roll back instead of rebuilding. The trade-offs are structural, not accidental. No joins, no foreign keys, no large blobs. The docs are explicit that a puma_live_ key is a bearer secret for server-side code and should not go in React bundles, static sites, mobile apps, or public repos—so anything browser-side needs a proxy. Table and row caps and per-key rate limits (30 writes, 60 reads per minute) shape what you can do at volume. Where it fits: prototyping, personal agent memory, small-team handoffs, system integrators stitching agent contexts together. Where it doesn't: high-throughput production, anything needing relational integrity, or storing media.