Multi-tenant memory for SaaS

If you're building a SaaS product on top of AI, you almost certainly need isolation per customer. Each customer's memory, files, and search must be theirs alone, with no chance of one tenant's data appearing in another's. The usual way to get there is to build multi-tenancy yourself: partition keys threaded through every query, isolation tests, and the standing worry that one missed filter somewhere becomes a data-leak incident.

Exabase Bases give you that isolation as a primitive. One API call creates a fully isolated environment, memory, files, search, all of it, scoped to a tenant and sealed off from every other. This page is about using Bases as your multi-tenancy layer so you can build the product instead of the partitioning.

The problem

Multi-tenancy is one of those things that sounds simple and turns out to be a permanent tax. The naive approach, a tenant ID column on every table and a filter on every query, works right up until someone writes a query that forgets the filter. And someone always does. The failure mode isn't a crash you'd notice in testing; it's a quiet leak where one customer sees another's data, which in most markets is the kind of incident that ends contracts.

Doing it properly means partition logic everywhere data is touched, isolation woven through memory, file storage, and search alike, and a test suite whose job is to prove the walls hold. That's a meaningful chunk of engineering before you've built anything a customer actually pays for, and it's load-bearing forever: every new feature has to respect the same boundaries.

The AI layer makes it harder, because the things that need isolating aren't just rows in a database. A tenant's memory has to be separate, their stored documents have to be separate, and their search index has to be separate, so a query for one tenant can't retrieve another's content. Building all three isolation boundaries yourself, and keeping them aligned, is a lot more than a tenant ID column.

What Exabase unlocks

With isolation as a primitive, the multi-tenancy problem mostly disappears into a single concept you create and forget about.

You spin up a Base per tenant with one call, and from then on everything you do for that tenant, storing memory, adding files, running search, is scoped to their Base and structurally can't touch anyone else's. There's no partition key to remember to include, because the Base is the boundary. The class of bug where a forgotten filter leaks data across tenants simply isn't expressible, since operations scoped to a Base can only ever see that Base.

It scales to as many tenants as you have. Creating the ten-thousandth Base is the same single call as creating the first, so onboarding a new customer is one API call rather than a provisioning project. You're not managing a partitioning scheme that gets more delicate as the tenant count climbs; each Base is independent.

And you get the whole isolated stack, not just isolated storage. Each tenant's Base holds their own memory, their own files, and their own search, aligned by construction, so you don't assemble isolation separately for three different systems and pray they agree.

How it works

Three primitives, with Bases as the isolation layer and Memory and Resources as what lives inside each isolated environment.

Bases

A Base is a fully isolated environment: its own memory, its own file storage, its own search index. It's the unit of multi-tenancy. You create one per tenant, hold the Base ID against your customer record, and scope every operation for that customer to it. Isolation is structural rather than enforced by application-level filters, which is the property that makes cross-contamination not a risk you mitigate but a thing that can't happen through the API. Creating a Base is a single call, so it scales from one tenant to many thousands without any change in how you do it.

Bases also support filesystem snapshotting, so you can checkpoint and roll back a tenant's state, which is useful for versioning agent context if you let agents operate on tenant data.

Memory

Exabase Memory, scoped to a Base, is the per-tenant memory you'd otherwise be building and isolating yourself. Each tenant's agent accumulates its own memory, sealed inside their Base, so the personalisation one customer gets is built only from their data. Whatever your product does with memory, remembering users, tracking context, personalising behaviour, it inherits the Base's isolation without you wiring up tenancy for it separately. The general value of a memory layer is covered in long-term memory for any agent; here the point is that it comes already partitioned.

Resources

Resources, also scoped to a Base, are each tenant's files and documents, stored and indexed for Deep Search inside their isolated environment. A search run for a tenant returns only their content, because the index belongs to their Base. You get per-tenant document storage and per-tenant search as part of the same boundary that isolates memory, rather than as a second isolation problem to solve.

Example architecture

The shape is about as simple as multi-tenancy gets, which is the entire selling point.

On customer signup, create a Base and store its ID against the customer record. That one call provisions their isolated memory, storage, and search together.

For every operation on behalf of that customer, scope it to their Base ID: write memory to their Base, store Resources in their Base, run search within their Base. There's no separate partition key and no cross-tenant query to guard against, because the Base scope is the isolation.

On customer offboarding, delete the Base and the tenant's data goes with it, cleanly, rather than leaving you to track down rows across multiple systems.

Each customer maps to one Base, every operation carries that Base's scope, and isolation follows automatically. Adding the next tenant is the same single call as the last.

What compounds over time

The argument for using isolation as a primitive rather than building it strengthens the longer the product lives and the more tenants it has.

Hand-built multi-tenancy gets riskier with scale and time. Every new feature is another surface where the partition boundary has to be respected, every new engineer is someone who has to learn where the walls are, and the test suite that guards isolation grows alongside the product as a permanent cost. The probability that some query, somewhere, eventually forgets its filter only rises. Building on Bases inverts that: the isolation boundary doesn't get more fragile as you add features, because individual features can't weaken a structural boundary they don't control.

Meanwhile the per-tenant memory inside each Base compounds in the ordinary way, each customer's agent getting more useful as their memory accumulates, since the memory self-organises. You get the compounding value of memory and the flat cost of isolation at the same time, which is the combination that's painful to build and maintain by hand.

Who's building this

Any team building a multi-tenant SaaS product on AI: per-customer assistants, vertical AI tools, white-label agent platforms, anything where each customer needs their own isolated memory, files, and search. It's also the underlying pattern behind a lot of the other use cases, the per-patient isolation in healthcare agents, the per-student isolation in learning copilots, the per-role pools in recruiting agents, and the per-customer setup in customer onboarding automation all rest on Bases as the isolation layer.

If you're building an internal tool rather than a customer-facing product, internal tools powered by AI covers the single-tenant version of the same infrastructure.

Get started

Start with the getting started guide, then about Bases, creating Bases, and memory scoping for how isolation works in practice. There's a free tier to build against.

FAQs

How is a Base different from just adding a tenant ID to my tables?

A tenant ID relies on every query remembering to filter by it, and the failure mode is a leak when one doesn't. A Base is a structural boundary: operations scoped to it can only see its data, so there's no filter to forget. Isolation is a property of the environment rather than something each query has to opt into.

Can one tenant's data ever appear in another's results?

Not through the API, provided each tenant has their own Base and operations are scoped to it. A search or memory query scoped to one Base cannot return another Base's content, because the index and memory belong to that Base alone.

How many tenants can I create?

Creating a Base is a single API call whether it's your first tenant or your ten-thousandth, and Bases are independent of one another, so the approach doesn't change as the tenant count grows. There's no partitioning scheme that gets more delicate with scale.

Does each Base really include memory, files, and search, or just storage?

All of it. A Base is a complete isolated environment with its own Memory, its own Resources for files, and its own Deep Search index. The three are isolated together by the same boundary rather than separately.

What happens when a customer leaves?

Delete their Base and their memory, files, and search index go with it, cleanly, rather than leaving you to find and remove their rows across multiple systems.

Can I roll back a tenant's state if something goes wrong?

Yes. Bases support filesystem snapshotting, so you can checkpoint a tenant's state and revert it. The version control for agent context use case covers that pattern in more depth.