A SaaS customer and a database tenant are not automatically the same boundary. One customer may have several business accounts, several customers may share one database tenant, or one customer may use several deployments. The mapping determines what a resource or operating claim actually means for the service.
OceanBase’s tenant-oriented resource model makes this an especially useful question during evaluation. The model should be connected to real customer identities and application behavior before the buyer concludes that a product-level tenant feature delivers customer-level isolation.
Draw the identities before choosing the layout
Ask what the SaaS business calls a customer. A legal customer, billing account, workspace, project, and end user may each have a different identity in the application.
Then identify the database objects used by those identities. Do not assume a product’s term for tenant matches the application’s term merely because both appear in the architecture diagram.
A hypothetical customer could own several workspaces that share a billing relationship but require separate access. That distinction matters even if the service places them in the same database tenant. The application still needs to explain who can see and change which records.
Describe the actual customer-to-database relationship
Use a mapping record rather than a slogan about shared or dedicated service.
| Possible mapping | Question it raises | Evidence to request |
|---|---|---|
| Several customers in one database tenant | How are customer identity and access preserved? | Application and supported control design |
| One customer in one database tenant | Which resources and operations align with that boundary? | Actual allocation and supported procedures |
| One customer across several tenants | How is the customer service coordinated? | Owned identity and operating map |
| Several workspaces in one customer account | Which workspace rights remain distinct? | Authorized role and record examples |
| Different deployments for selected customers | What justifies the additional boundary? | Service requirements and operating cost |
These are design possibilities to investigate, not a claim that every database supports each layout in the same way.
Read OceanBase resource evidence at its own boundary
OceanBase’s tenant resource documentation provides a concrete resource-allocation starting point. Apply it to the database tenant in the actual proposal.
If several SaaS customers share that tenant, the application needs an additional explanation of their service relationship. A resource boundary for the group should not be reported as a dedicated allocation for every individual customer.
Likewise, a one-to-one mapping does not automatically establish independent upgrades, physical separation, or a complete customer-level recovery service. Ask for the supported behavior of the chosen deployment instead of inferring it from the identity map.
Compare other layouts with the same customer promise
Google’s Spanner multi-tenancy guide describes instance, database, table, and row patterns. The examples illustrate why the object chosen to hold a customer can change the operating boundary.
Compare each arrangement against the same promised access, workload protection, recovery, and lifecycle behavior. A dedicated deployment and shared rows should not be treated as identical services differing only in storage price.
The current application layout can remain a credible baseline. A new database model should demonstrate which customer requirements it makes easier and what application responsibilities continue.
Trace one customer request through the map
Choose a customer with more than one relevant identity, such as separate workspaces or administrators. Follow an ordinary request and a supported customer lifecycle operation through the proposed arrangement.
Observe which boundary determines access, resource use, and operating authority. Ask the team to locate the same customer across monitoring, support, and any retained records.
Include another customer with similar data or activity. The service should preserve the required distinction without depending on a staff member recognizing a familiar customer name.
The exercise is a proposed acceptance test, not a completed isolation certification. Record unanswered mapping questions as requirements before attempting to compare product performance.
Keep the map current as the SaaS service grows
Make ownership of the mapping explicit. A customer gaining a new workspace, changing service tier, or moving to another placement can affect the relationship even when the database engine stays unchanged.
Preserve the accepted customer examples when the layout changes. The organization should be able to explain what moved and which service promise remains in force.
Include the support identity in the mapping. A customer may quote a billing account while an operator searches by workspace or database tenant. The service needs a controlled way to relate those identities without accidentally treating access to one as authority over all of them. This is a practical acceptance example, not a demand that every product adopt the same identifier. The result should let an authorized team locate the correct service boundary and explain its scope consistently.
OceanBase can be attractive when its supported tenant model aligns with the SaaS service’s real boundaries. The useful result is a clear mapping from customer promise to application identity and database behavior, so that isolation claims refer to the customer service actually being delivered.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.