Inside OceanBase Multi-Tenancy: Resource Isolation, Allocation and Governance

A Multi-System Resource Dilemma

As a company grows, it often expands into multiple business lines: orders, payments, users, marketing, and reporting. Each line may run on its own MySQL instance. At first glance, this seems sensible: each system has clear ownership, its own database, and a limited blast radius when something goes wrong.

But over time, the same problem shows up in cost reports and operations schedules: database instances keep multiplying, while the underlying resources remain underutilized.

• Five instances, five machines: Even if the payment database uses less than 20% of its machine's resources, the team may hesitate to place another database on the same machine. If resource contention occurs, it could quickly become a production incident.
• Five instances, five operations workflows: Monitoring is configured separately. Backups are handled separately. Upgrade windows are scheduled separately. The operations team constantly switches between tools, processes, and maintenance routines.
• Consolidation is attractive but risky: If multiple systems share one instance, a marketing batch job could cause latency spikes in the payment workflow. Moving to a conventional cloud database does not necessarily solve the problem if isolation is too coarse to provide application-level guarantees and clear responsibility boundaries.

This reflects a structural trade-off in traditional database management: independent instances improve separation but waste resources; shared instances improve utilization but create interference; and conventional cloud databases may still fall short when fine-grained isolation is required.

Five instances mean five machines, five sets of operational workflows, and five sets of licensing costs — and that is only a small or mid-sized scenario. For financial institutions, government agencies, large enterprises, or internet platforms with hundreds of business systems, database instances grow linearly, along with cost, management complexity, and stability risks.

The real question is whether one database system can support many workloads while still providing isolation, resource efficiency, centralized management, and the flexibility to adjust resources by workload, SLA, and business priority.

The Multi-System Database Trade-Off

As business systems multiply, organizations usually face three options: run separate instances, share one instance, or move to a cloud database. In production, each option comes with trade-offs.

Independent Instances: Safe but Wasteful

Independent instances provide clear separation between business systems, with clear ownership and separated failure domains. But even a small database may occupy a dedicated machine, regardless of how little capacity it actually uses.

This creates a practical dilemma: how many databases can safely run on one machine?

With only one database per machine, resources may sit idle for long periods. With multiple databases on the same machine, stability becomes harder to predict. If one database runs a batch job and consumes most of the available I/O, another database's online transactions may experience latency spikes.

Traditional architectures struggle to avoid resource waste and prevent cross-system interference at the same time. As a result, N small databases often turn into N machines, and hardware, operations, and licensing costs all grow linearly with the number of instances.

The bigger issue is operational fragmentation. N instances mean N monitoring setups, N backup strategies, and N upgrade workflows, so the operations team spends much of its time on repetitive instance-level management.

Shared Instances: Cheaper but Unstable

To reduce costs, some companies place multiple business systems in the same database instance. This lowers infrastructure costs at first, but makes performance much harder to control.

A marketing batch job may increase latency on the payment path. A large reporting query may cause core order writes to queue up. Business teams complain, user experience suffers, and eventually the database is split back into independent instances — leaving the organization where it started.

Cloud Databases: Isolation Still Falls Short

Managed services such as Amazon RDS and Aurora do offer separation, but it lands primarily at the instance or schema level: you get another instance, or another schema inside one, with no quota you can set per workload. Neither gives you a knob to cap CPU, memory, and I/O for the reporting workload specifically.

For industries such as finance, teams also need clear separation between core and peripheral systems, operation auditing, and traceability for regulators and internal governance. If resource isolation cannot be defined and enforced at the workload level, technical teams may still lack confidence in compliance and SLA guarantees.

What enterprises need is a way out of the trade-off: a database architecture that provides clear isolation boundaries like independent instances, delivers higher resource utilization like a shared instance, and still allows resources and isolation policies to be adjusted as business requirements change.

Breaking the Trade-Off with OceanBase Multi-Tenancy

The traditional model is like standalone houses — each one needs its own utilities, security, and maintenance, and management costs grow with every house. A multi-tenant architecture is more like a managed office building: each tenant has private space, the building shares power and security, and day-to-day operations run through a central management layer. In OceanBase, that layer is OceanBase Cloud Platform (OCP).

OceanBase multi-tenancy changes the resource model from fixed instance ownership to flexible tenant-based governance. Workloads can be placed, isolated, scaled, and managed according to business priority, workload characteristics, and SLA requirements.

Resource Pooling: No Dedicated Machine per Small Database

Instead of binding resources permanently to individual database instances, OceanBase pools cluster resources and allocates them along a three-step chain: Unit Config → Resource Pool → Tenant.

A unit config defines the resource specification available on a single OBServer node in a single zone. A resource pool groups units of that spec and places them across zones. A tenant then binds one or more pools, and the total resource it receives is unit spec × unit count:

-- 1. Define the resource specification (run as root@sys)
CREATE RESOURCE UNIT payment_unit
  MAX_CPU 8, MIN_CPU 8,
  MEMORY_SIZE '32G',
  MAX_IOPS 20000, MIN_IOPS 12000,
  LOG_DISK_SIZE '96G';

-- 2. Group units into a pool and place them across zones
CREATE RESOURCE POOL payment_pool
  UNIT = 'payment_unit', UNIT_NUM = 1, ZONE_LIST = ('zone1','zone2','zone3');

-- 3. Bind the pool to a tenant
CREATE TENANT payment_tenant
  PRIMARY_ZONE = 'zone1', RESOURCE_POOL_LIST = ('payment_pool');

This changes the resource model: payment receives a stable quota, marketing draws resources on demand, and reporting queries stay inside their own boundaries. Specifications can be changed later with ALTER RESOURCE UNIT, which takes effect without migrating data or restarting the tenant.

The key point is simple: consolidation does not mean uncontrolled resource sharing. Workloads run in the same cluster while remaining governed by tenant-level resource controls.

Fine-Grained Isolation: Critical Workloads Stay Protected

The isolation guarantee comes from how MIN_CPU and MAX_CPU interact. MAX_CPU caps what a tenant can consume; MIN_CPU is the floor it is always entitled to. Critically, the sum of all tenants' MIN_CPU on a node cannot exceed that node's CPU capacity — so a reserved floor is genuinely reserved, not merely requested. Setting MAX_CPU above MIN_CPU lets idle capacity be borrowed during quiet periods and reclaimed when the guaranteed tenant needs it.

Underneath, OceanBase controls tenant CPU by limiting each tenant's active worker threads, and recent versions add cgroup-based isolation for CPU and IOPS. Within a tenant, DBMS_RESOURCE_MANAGER can bind specific users, SQL patterns, or background tasks (major compaction, backup, DDL) to separate resource groups.

There is also a guard for the classic offender — the long-running query. Any statement exceeding large_query_threshold is classified as a large query, and large_query_worker_percentage (default 30%) caps the share of a tenant's worker threads such queries can occupy, so a reporting scan cannot starve short transactions.

Performance assurance therefore no longer depends solely on physical separation. Workloads can be separated by business criticality, SLA level, compliance requirement, customer tier, or traffic pattern, without deploying a separate physical instance for every boundary.

Centralized Management: OCP as the Control Plane

OCP acts as the control plane for the OceanBase environment, managing clusters and tenants in one place:

• Monitoring: View the status of clusters and tenants, and prioritize alerts for critical tenants.
• Operations: Perform scaling, configuration changes, and failover from one place, instead of handling each instance separately.
• Backup and upgrades: Apply unified policies and schedules, rather than maintaining separate plans for every instance.

The operations team shifts from managing individual instances to orchestrating the database environment as a whole — adjusting resources, responding to workload changes, and applying policies centrally.

What Consolidation Gives Up

Tenant-based governance is not free, and the constraints are worth knowing before you size a cluster:

• Memory cannot be over-committed. Since V4.0.0, OceanBase no longer supports memory over-commit. CPU can be over-subscribed via MAX_CPU > MIN_CPU, but memory must be budgeted for real. Plan capacity against the sum of tenant MEMORY_SIZE, not against hoped-for averages.
• cgroup isolation has an OS dependency. It requires Linux kernel 4.19 or later, must be reconfigured after a database upgrade or OBServer restart, and carries enough performance overhead that it is not recommended for every workload.
• Not everything is per-tenant. Network threads are shared across tenants, so isolation is strong for CPU, memory, and IOPS but not absolute at every layer.
• A cluster is still a blast radius. Consolidation trades N failure domains for one well-managed one. Workloads with genuinely independent availability requirements — or a regulatory mandate for physical separation — may still warrant separate clusters.

Flexibility in Practice: Four Business Benefits

Cost: Flexible Resource Allocation Reduces Waste

Five small databases that once required five instances and five machines can be consolidated into a smaller number of cluster nodes, with CPU, memory, and I/O allocated through tenant quotas. Core transaction tenants receive stable quotas; non-core tenants such as marketing and reporting draw resources on demand. This reduces idle waste without reserving excessive peak capacity for every instance.

At the infrastructure level, OceanBase runs on general-purpose x86 and ARM servers, reducing dependence on mainframes, minicomputers, or dedicated storage. Its LSM-tree-based compression engine reduces storage cost by 70%–90% according to OceanBase's product documentation, though the realized ratio depends on data types and workload.

Performance: Flexible Isolation Makes SLAs More Predictable

Core and peripheral systems, transactional and batch workloads, and online services and offline analytics can be separated into different tenants, each with its own CPU, memory, and IOPS quotas. Performance assurance moves from physical separation to quota-based governance: SLAs for critical business paths become more predictable, while non-core workloads retain the flexibility to use resources when capacity is available.

Efficiency: Flexible Operations Through One Control Plane

With OCP, teams view cluster and tenant status in one place and centrally perform monitoring, operations, backups, and upgrades — rather than checking and maintaining instances one by one. The same platform provides a unified SQL dialect, monitoring framework, backup mechanism, and operations model, which reduces collaboration costs across development, testing, and operations teams.

Compliance: Flexible Boundaries Without Redundant Deployments

Different business systems run in different tenants, with resources and permissions isolated and operations auditable. This makes key audit and regulatory questions easier to answer: who accessed what, who performed which operation, and what was the scope of impact.

It also reduces the need to build separate physical instances solely for isolation. Where enterprises once deployed multiple databases to separate core and peripheral systems, production and analytics workloads, or different customer environments, tenant boundaries in a unified cluster can now carry that requirement.

Where Multi-Tenancy Fits

Different industries face similar multi-system management challenges but prioritize different outcomes.

Fintech: Isolating Core Systems

Requirement: Core systems such as accounting, payments, and clearing must be isolated from peripheral systems such as channels and reporting. They must be auditable, and query or batch peaks from peripheral systems must not affect online core services. Regulators also require clear data isolation and operation traceability.

OceanBase approach: Core and peripheral systems are placed in different tenants, with tenant-level CPU, memory, and IOPS quotas providing resource isolation. OCP centrally monitors all tenants and prioritizes alerts for core tenants.

Value: Unified monitoring, backup, change management, and permission models simplify compliance and auditing. SLAs for core business systems become more predictable, and peripheral systems manage capacity within their own tenant boundaries.

E-Commerce: Handling Traffic Spikes

Requirement: Daily traffic is relatively stable, but major sales campaigns cause sharp spikes. Core transaction and order paths must maintain their SLAs, while non-core systems such as marketing and recommendation services need elastic scaling. Marketing batch jobs and campaign data synchronization must not affect transaction paths.

OceanBase approach: Transactions and marketing are placed in different tenants. The core transaction tenant receives a reserved MIN_CPU floor to reduce peak-time volatility, while the marketing tenant scales out before campaigns and scales back afterward via ALTER RESOURCE UNIT.

Value: Core transaction performance remains stable during promotions. Non-core workloads scale elastically, avoiding waste during normal periods while still handling campaign peaks.

SaaS: Scaling Customer Tenants

Requirement: SaaS platforms usually avoid deploying a separate database for every customer. Many small and mid-sized customers share database resources, while large, strategic, or high-compliance customers receive stronger isolation. As customers and service tiers increase, the platform must balance shared-resource efficiency with stronger isolation for key customers.

OceanBase approach: Within a single cluster, tenants are organized by customer tier or isolation requirement. Standard customers share pooled resources; key customers use dedicated tenants. Resource quotas map to service tiers such as Basic, Professional, and Enterprise, and OCP provides unified management for all customer tenants.

Value: Standard customers share a resource pool, avoiding the waste of a dedicated instance per customer, while key customers receive clearer data and performance boundaries. Onboarding simplifies from "request an instance, deploy, and configure" to "select a tenant model and assign quotas."

When to Adopt Multi-Tenancy

A multi-tenant database architecture is a strong fit when several of the following exist together:

1. Many business systems: The number of database instances has become difficult to manage across development, testing, operations, and governance.
2. Underutilized small databases: Dedicated machines sit idle for long periods, leaving capacity wasted.
3. Centralized management needs: Clusters and tenants must be managed in one place through a platform such as OCP.
4. Fine-grained isolation requirements: Core and non-core workloads require different SLA guarantees and must not interfere with each other.
5. Elastic resource requirements: Some workloads need stable reserved resources, while others scale up or down based on campaigns, reporting peaks, or customer growth.
6. Rising cost pressure: Hardware, cloud resources, storage, licensing, and operations costs continue to increase.

Conclusion: One Database System, Flexible Workload Governance

Independent instances may provide clear boundaries initially, but over time they lead to low resource utilization, fragmented operations, and rising costs.

OceanBase's multi-tenant architecture offers a different model. Multiple workloads run in one database system while remaining isolated through tenant-level resource controls: core systems receive guaranteed MIN_CPU floors, non-core workloads stay within MAX_CPU ceilings, and OCP provides centralized management across clusters and tenants. The value is not simply reducing the number of machines — it is gaining the ability to place workloads, allocate resources, enforce isolation, and manage operations from one platform. Not uncontrolled sharing, but flexible resource governance with clear tenant boundaries.

Try it yourself: the fastest way to see tenant isolation in practice is to create two tenants with different MIN_CPU floors on one cluster and run a batch workload against one while measuring latency on the other. OceanBase Community Edition is free, and the tenant management and resource isolation documentation covers the full CREATE RESOURCE UNIT and DBMS_RESOURCE_MANAGER reference.