LeapMemory
BUILT WITH TENANTSDB /
LeapMemory
LeapMemory
A long-term memory API for AI systems. Saved context, recall events, and user-specific knowledge stay physically separated per workspace from the first write.
Built with TenantsDB
VIA TENANTSDB
pg · mongo · redis
WEB
leapmemory.com
THE PROBLEM
Memory is the most personal data a product can hold
A memory product stores what people say, decide, and care about. In a conventional multi-tenant architecture, all of that would sit in shared tables, separated only by a tenant_id column and a WHERE clause in application code. For most SaaS data that is an accepted tradeoff. For an AI memory layer it is not. One filtering bug is not a glitch, it is a leak of someone's private context into another workspace.
Row-level security and query filters are logical isolation. They depend on every code path being correct forever. LeapMemory needed physical data isolation between workspaces, with hard boundaries at the database layer, without building and operating its own database fleet to get it.
HOW IT USES TENANTSDB
One blueprint, one physical database per workspace
LeapMemory runs on a database-per-tenant model, provisioned through TenantsDB. When a new workspace is created, TenantsDB provisions dedicated MongoDB and Redis databases for it automatically, each with its own connection boundary, its own credentials, and its own resource limits. MongoDB holds the workspace's long-term memory, the stored conversation turns and memory chunks, while Redis carries its hot state and caching. The memory graph of one workspace can never touch another's, because they never share storage. There is no tenant_id column to filter on and no shared table to filter.
Schema management stays as simple as a single database. Changes ship once as a versioned blueprint, and TenantsDB deploys them identically across every workspace database in the fleet, so there is no schema drift and no per-database migration scripts. The control plane runs on the same platform too. Every product needs one, a database for organizations, projects, workspaces, and usage, and TenantsDB hosts it as simply another tenant, on PostgreSQL in LeapMemory's case. Product data and product operations both live on one infrastructure layer, and the result is the isolation profile of hundreds of separate databases with the operational overhead of one.