Ship multi-tenant without building the infra

The question usually arrives in a sales call. A prospective customer asks how their data is kept separate from other customers' data, and you realise the honest answer is not good enough. Perhaps you filter by user_id in queries. Perhaps you use namespaces in a vector database. Perhaps there is no real isolation at all, because until this conversation nobody needed it.

This page is for teams whose product has started to serve customers who care about that answer. The deal is live, the buyer has a security review, and the prerequisite is infrastructure you have not built.

What you have probably already tried

The interim answers all have the same shape: they work, until someone asks how they work.

Filtering by user_id is correct until one query forgets the filter. The failure is silent, it surfaces as one customer seeing another's data, and it is not a bug you get to fix quietly. It is also unpersuasive in a security review, because the reviewer's next question is how you guarantee every current and future query includes it.

Namespaces in a vector database isolate the vectors and nothing else. Your files, your memory, your extraction outputs, and your search indexes are separate systems with separate isolation stories, and the buyer is asking about all of them.

Separate database rows with a tenant column is the same trust model as user_id filtering, one layer down, and carries the same burden of proving every access path respects it.

Building it properly yourself means provisioning storage per customer, standing up per-tenant search indexes, scoping memory correctly, adding an auth layer, and building an admin interface so you can debug what happened inside a tenant you cannot query directly. That is months of infrastructure work, and you are trying to close a deal this quarter.

The common problem is that isolation implemented as a filter is a promise about your code's discipline. Isolation implemented as an environment is a property of the system, and only the second one survives a serious security review.

How Exabase handles this

A Base is a complete, isolated environment you create on demand. One API call, give it a name, ready immediately.

Each Base has its own file storage, folders, tags, memory, search index, extraction pipeline, and Workers. Data in one Base is invisible to another, and that is enforced at the infrastructure level rather than by filtering query results. Search returns results from the current Base only. Memory is scoped to the Base. Workers operate inside their own Base and nowhere else.

Scoping is a header rather than a per-endpoint concern. Pass the Base ID on any API call and every operation, whether that is Resources, Memory, Deep Search, Extract, or Workers, scopes to that Base automatically. There is no configuration to repeat and no code path that can quietly omit it.

Create one Base per customer, per user, or per project, whichever matches how your product is sold. Usage rolls up to your account, and your tenants never need Exabase accounts or interact with Exabase directly. As far as they are concerned it is your product.

The console gives you the admin interface you would otherwise have built. Browse any Base through a visual workspace explorer and see every file, note, and memory your agent created inside that tenant's environment, which is how you debug agent behaviour without querying across isolation boundaries.

Creating a Base is the same single call whether it is your first tenant or your ten-thousandth, so onboarding does not become a provisioning project as you grow. Current limits by plan are on the pricing page.

What changes

The security-review answer becomes a short one. Each customer's data lives in a separate environment with its own storage, memory, and search index, isolation is enforced by the infrastructure rather than by application filtering, and no query can reach across the boundary because operations are scoped to a Base by construction.

The engineering answer changes too. Multi-tenancy stops being a project and becomes a parameter, which means the version of your product that serves one customer and the version that serves a thousand are the same code.

For the fuller architectural picture, multi-tenant memory for SaaS walks through the pattern end to end, and if the isolation requirement is coming from a regulated buyer, compliance and audit trails covers the accountability side that usually arrives in the same conversation.

Get started

The Bases page has the API detail. Multi-tenant memory for SaaS is the end-to-end pattern, and the industry pages for SaaS, healthcare, and banking cover sector-specific isolation requirements. There is a free tier to build against.

FAQs

How is this different from filtering by user_id?

Filtering is a promise that every query in your codebase, now and in future, remembers to include the filter. A Base is a separate environment, so an operation scoped to one cannot reach another's data regardless of what the query says. The difference matters most in a security review, where the reviewer is assessing the guarantee rather than the intention.

What exactly is isolated?

File storage, folders, tags, memory, the search index, the extraction pipeline, and Workers. Not just vectors. Each Base is a complete environment rather than a partition of one shared system.

How long does it take to create a tenant?

One API call, ready immediately, and it is the same call whether it is your first tenant or your ten-thousandth. There is no provisioning step that gets slower as you scale.

Do my customers need Exabase accounts?

No. Usage rolls up to your developer account and your tenants never interact with Exabase directly. It is infrastructure inside your product rather than a service they sign up for.

How do I debug what an agent did inside a customer's environment?

The console has a visual workspace explorer for any Base, showing every file, note, and memory the agent created there. That replaces the internal admin tool teams usually build for this, and it means you can inspect a tenant without writing queries that cross isolation boundaries.

Does scoping have to be repeated on every endpoint?

No. Pass the Base ID as a header and every operation scopes automatically, so there is no per-endpoint configuration and no code path that can accidentally run unscoped.

Can I use Bases for something other than customers?

Yes. One per user, per project, per case, or per agent all work. The Base is the isolation unit and you choose what it represents, which is why the same primitive covers per-patient records, per-matter legal work, and per-repo project context.

How many Bases can I create?

Limits vary by plan and are listed on the pricing page. Creation is instant regardless of how many you have.