Multi tenant SaaS architecture: Shared core or client integrations
Multi tenant SaaS architecture favors a shared core with tenant-specific connectors, adding dedicated resources when isolation or workload needs require them.
A SaaS team integrating customer knowledge needs to separate reusable product behavior from tenant-specific configuration, connector code, and resource isolation. Compare those boundaries through onboarding, source changes, release rollout, and offboarding. The decision is which customer differences a shared core can handle safely and sustainably.
Key takeaways
Choose among shared-core, per-client, and hybrid approaches according to tenant variation, isolation needs, and the work your team can operate.
- Start with a shared core for services, schemas, and retrieval steps that genuinely stay common.
- Add tenant-specific connectors when customers use different source systems, credentials, or refresh needs.
- Isolate data and workloads at the boundary required by your security, performance, and service commitments.
- Reserve dedicated resources for tenants whose isolation or workload needs justify the added provisioning and upkeep.
What work should the comparison include?
A useful comparison tracks repeatable work and tenant-specific work separately. Repeatable work includes building common ingestion and retrieval functions, deploying them, testing shared changes, and monitoring service health. Tenant-specific work includes registering a tenant, connecting its sources, configuring access, setting refresh behavior, and managing changes to its systems.
Separate the initial engineering bill from the repeated operating bill. For each new tenant, estimate whether the existing connector can be configured or whether its source calls for new integration code, tests, credentials, error handling, and support. When customers use the same source system and workflow, a shared connector keeps that integration logic in one implementation; tenant-specific configuration can handle differences such as credentials or refresh schedules.
Treat content refresh and product expansion as different work. A source refresh changes or re-indexes the content a tenant already uses; adding another department or workflow expands the tenant’s scope. Each has its own trigger, access checks, testing, and ownership, so estimate both rather than counting all updates as one generic “sync” task.
How much tenant isolation does the design need?
Choose the data and workload boundary from each tenant’s security, performance, residency, and service commitments. The Azure tenancy-model guidance notes that shared infrastructure can cost less, while resource contention can degrade performance and a problem in one shared component can affect all tenants.
| Knowledge-integration approach | Best fit and tenant variation | Isolation decision | Onboarding and change work | Offboarding and ongoing work |
|---|---|---|---|---|
| Shared knowledge core | Use when source systems and workflows are common; represent bounded customer differences through tenant configuration | Choose the data, index, and authorization boundary separately; shared connector code does not itself separate tenant data | Establish the common tenant setup path; assess shared source changes and test their effect across the tenant group | Operate common services and pooled capacity; revoke access and credentials promptly, then apply documented retention and deletion rules |
| Per-client integrations | Use when a customer’s source systems or processing rules need distinct integration behavior | Connector separation does not determine data isolation; set the storage, retrieval, and authorization boundary to the tenant’s requirements | Estimate source mapping, credentials, tests, and change handling for each integration | Track each integration’s content, credentials, configuration, and removal steps, along with any tenant-specific resources |
| Shared core with tenant-specific connectors | Use when common ingestion or retrieval functions coexist with customer-specific sources or settings | Keep the infrastructure choice separate; use shared, tenant-specific, or dedicated data and retrieval resources according to requirements | Reuse the common setup path where it fits and plan the source-specific configuration or connector steps for each tenant | Operate common services alongside connector-specific cleanup and any selected dedicated-resource teardown |
Logical isolation in shared services still needs explicit identity and authorization design. Resolve tenant identity from authenticated identity and authorized context; a caller-selected tenant ID alone is not sufficient. Validate that the authenticated user or service is permitted to act for the resolved tenant, and carry that authorized context through every request and background operation.
Bind cache keys, queued jobs and retries, exports, and credentials to the authorized tenant. Test cross-tenant access denial, and verify that revoked users and credentials can no longer access tenant data.
Knowledge retrieval can use intermediate boundaries instead of choosing only between one shared index and a completely separate platform. The Azure AI Search multitenancy guide describes one index per tenant within a shared search service, a dedicated service per tenant, and a hybrid arrangement. In its hybrid model, larger or more active tenants can use dedicated services while smaller tenants use separate indexes in shared services.
An index-per-tenant design adds tenant routing and service-level resource management to the application. A dedicated Azure AI Search service offers the highest data and workload separation among the search models in that guidance.
When do customer-specific connectors earn their place?
Make a connector tenant-specific when the external system or its operating rules differ in a way the common path cannot safely or simply configure. Customer-specific differences can include source type, authentication, allowed content, refresh frequency, document processing, or retrieval settings. Keep the shared core responsible for common workflow and policy enforcement; place the customer-specific source mapping and configuration at a boundary that can be tested independently.
A shared connector fits when several customers use the same source product and the same connection pattern. Give each tenant its own configuration and credentials, and route jobs and results through tenant-aware boundaries. This keeps reusable integration logic in one place while allowing a customer to use its own source account, permissions, and refresh schedule.
Which pattern makes onboarding and offboarding easier?
Offboarding takes more than deleting a tenant’s application account. Revoke user access and source credentials promptly.
Retention does not imply continued user access: restrict access to any retained copies, and apply documented retention and deletion rules to derived indexes, caches, and backups. Define when retention applies, who may access retained material, how deletion is handled, and how re-onboarding works in line with the service’s contractual and legal requirements. Do not treat a deletion request as proof that every copy has already been removed.
| Lifecycle event | Shared core with tenant-specific connectors | Dedicated tenant resources |
|---|---|---|
| Onboarding | Add tenant identity and configuration; attach sources; provision only tenant-level resources the design requires | Create the tenant stack and its resources; connect sources and register routing |
| Source change | Update that tenant’s source configuration or connector; verify its refresh and access behavior | Update the tenant’s connector and stack; verify the tenant’s pipeline |
| Common product release | Test and roll out the common path; manage impact across the pooled tenant group | Apply the release across stacks or coordinate tenant-specific rollout waves |
| Offboarding | Revoke access and credentials promptly; restrict any retained copies; apply documented retention and deletion rules to content, indexes, caches, and backups | Revoke access and credentials promptly; restrict any retained copies; apply documented retention and deletion rules to content, indexes, caches, backups, and dedicated resources |
For shared resources, assess whether tenant allocations need rebalancing after offboarding. For dedicated stacks, the team has a clearer resource boundary to remove, but still needs a complete inventory and a controlled deletion process. In either pattern, verify revoked access and credentials, including denial of cross-tenant requests; freshness timing and authorization acceptance are separate checks.
Where does AKB fit?
Dnotitia’s AKB is described as providing organizational knowledge and memory to AI agents through the Model Context Protocol (MCP). That organizational knowledge role is separate from a SaaS team’s responsibility to design and validate tenant-specific identity, authorization, data boundaries, and lifecycle controls. Do not treat AKB as turnkey SaaS tenant isolation; validate the relevant isolation and access controls for the architecture and deployment you choose.
Before adopting AKB, check the license for the exact deployed release and confirm that the intended commercial, hosted, or embedded use is permitted. See the official AKB LICENSE; do not infer permissions from a different release or deployment model.
Which design fits your tenant mix?
Before committing, answer these five questions with the product team:
- Set the boundary: Which tenant data, credentials, indexes, or compute resources must be isolated, and at what level?
- Group common work: Which source types, document steps, retrieval behavior, and refresh schedules can use one tested implementation?
- Price lifecycle operations: What does onboarding, source change, release rollout, offboarding, and re-onboarding require in each pattern?
- Test noisy-neighbor behavior: Which tenant workloads can affect shared performance, and what capacity or placement signals trigger a move to dedicated resources?
- Assign owners: Who approves source access, connector changes, access revocation, retention decisions, and removal verification?
Operational checks before rollout
Keep a proposed lifecycle worksheet per tenant: source type/version, configuration or custom connector, credentials and authorized audience, data/index/cache boundary, owner, onboarding hours, recurring refresh/repair hours, and offboarding evidence.
Compare the same operating period and service target. Record service fees, internal work, incidents, and planned exit once each; use pilot values or label planning assumptions rather than implying a universal per-tenant savings rate.
Run a cross-tenant test with separate tenant and user identities. Check direct reads, search, snippets, citations, cache hits, exports, and background jobs and retries. Verify tenant identity comes from authenticated and authorized context rather than a caller-selected ID alone.
Revoke a user and credentials, then verify access is denied. Offboard a test tenant under its documented retention rules and confirm the other tenant keeps working. Record routing inputs, affected resource IDs, timestamps, results, and unresolved failures. Shared code and index separation are design choices; observed authorization and workload behavior are separate acceptance evidence.
For each new tenant, verify its configuration or connector and test tenant-aware routing, retrieval, and offboarding; shared connector code alone does not prove isolation.
Related background: Expanding Agent Knowledge to a New Team Without Rebuilding
FAQ
What is a SaaS tenant?
A SaaS tenant is a customer or organization using a shared software service. The architecture determines which application, data, and infrastructure resources that customer shares with other tenants and which it receives separately.
What does “multi-tenant” mean?
“Multi-tenant” means one software service supports multiple customers. Azure guidance calls for separating each tenant’s data and preventing cross-tenant data exposure. Teams can share application components while separating selected data or compute resources according to their isolation requirements.
Is a shared knowledge backend always less work?
No. A shared design requires tenant-aware authorization and management of pooled capacity; Azure guidance notes that resource contention can affect performance and shared-component problems can affect multiple tenants. Dedicated resources offer a separate boundary, and a hybrid can reserve them for tenants whose needs call for it; plan the provisioning, updates, monitoring, and removal work for each operating path.
When should a SaaS team use a dedicated tenant environment?
Use a dedicated environment when a customer’s data separation, workload, performance, geographic, or contractual requirements call for its own resources. Automate deployment, update, monitoring, and teardown so the separate boundary does not become a manual runbook for every tenant.
Read the AKB documentation
Review the documented knowledge and integration workflows for your AKB deployment.
