OceanBase Tenant-Level Scaling: Adjust Resources in Seconds

Traffic fluctuations are inevitable for online services. For many platform engineers and DBAs, the real challenge is not necessarily a consistently high volume of traffic, but traffic that is highly volatile and unpredictable. Promotional events, product launches, flash sales, and new game releases can all create sudden traffic spikes. Estimating database capacity requirements for these events in advance is difficult, and traditional database scaling is often slow, tedious, and involves operational risk.

To ensure system stability during a major event—such as a highly anticipated game launch or a limited-edition product release—engineers are often forced to perform database scaling during off-peak hours, often late at night.

Scaling traditional single-node databases like MySQL requires upgrading the server specification, which involves provisioning a new machine, syncing data, and performing a primary-standby switchover. Even with modern cloud-native databases like Amazon Aurora, which eliminate some data migration overhead, upgrading compute instances still requires a restart or a failover that can cause brief connection interruptions. The entire process is time-consuming, and because the switchover can cause service interruptions, it usually has to be scheduled in a maintenance window.

Worse still, to play it safe, engineers often over-provision resources based on the most extreme scenarios. Once the event ends, they must go through the same cumbersome downscaling process all over again.

OceanBase handles this differently: adjusting a tenant's resources is a quota change inside the kernel, which takes effect in seconds and is transparent to applications.

How OceanBase Manages Tenant Resources

Tenant-level scaling is a change to a tenant's resource quota, so it helps to start with how OceanBase defines those quotas.

As a native distributed database, OceanBase organizes multiple physical servers into a unified cluster. On top of this cluster, OceanBase introduces the concept of tenants. A tenant can be understood as an independent database instance running within the cluster. Each tenant has its own data and resource quotas, and is fully isolated from other tenants. To an application, connecting to a tenant is identical to connecting to a standalone MySQL or Oracle database instance.

This multi-tenant architecture is powered by a fine-grained resource management system:

• Unit config: Defines the allocation of physical resources, including CPU, memory, IOPS, and transaction log disk space.
• Resource unit: The actual allocation unit for these physical resources, distributed across the nodes of the cluster.
• Resource pool: A collection of resource units. A tenant obtains its required compute and storage resources by being associated with a resource pool.

To use an analogy, think of an OceanBase cluster as a large business park, where the physical servers are the office buildings. When a company (a tenant) moves into the park, it leases a package of offices (a resource pool) spread across different buildings. Each individual office is a resource unit. The layout of the office—whether it is configured for 10 or 20 workstations—is defined by the unit config.

Scaling by Adjusting Unit Configs

In OceanBase, tenant-level scaling can be achieved through two primary paths:

1. Adjusting the unit config to increase resource quotas within the existing nodes.
2. Adding nodes or additional zones to scale out horizontally.

This article focuses on the first method—adjusting the unit config—which is a convenient way to address capacity bottlenecks.

Adjusting the unit config is a vertical scaling mechanism applied at the tenant level. By modifying a tenant's unit config, you can quickly increase or decrease the CPU, memory, and IOPS allocated to that tenant on each node.

Returning to our office analogy: this is equivalent to keeping the number of offices the same but adding more desks and chairs to each existing office to accommodate more employees. Because this process does not require moving any data, the configuration change takes effect in seconds. When a sudden traffic spike hits, administrators can adjust the tenant's resource specifications at any time—even during peak business hours—quickly increasing the tenant's processing capacity.

But where do the extra CPU and memory come from?

This scaling mechanism assumes that the physical nodes have unallocated, schedulable resources (which administrators can monitor in real time via system views). The cluster does not create additional resources on its own. Instead, it reallocates available physical resources within the existing cluster to the target tenant. This spare capacity typically comes from two sources:

• Reserved resources on each node: When a cluster is deployed, not all physical resources on each machine are assigned to tenants. Some CPU and memory are usually left unallocated for emergency scaling.
• Idle resources from tenants under lighter load: In OceanBase's multi-tenant architecture, workloads from different business lines often reach their busiest periods at different times. For example, consumer-facing services may see heavier traffic in the evening, while internal enterprise systems are usually busier during working hours. Administrators can temporarily allocate idle resources from tenants that are currently under lighter load to a tenant experiencing a sudden traffic surge. This time-based resource reuse improves overall resource utilization.

Does this online resource adjustment affect other tenants running in the same cluster? It does not, as long as the cluster has sufficient overall resources. Increasing the quota for Tenant A simply assigns previously unallocated resources to Tenant A's resource pool. The existing quotas for Tenant B remain unchanged, and its services continue running without disruption. (We will explore OceanBase's tenant resource isolation mechanisms in an upcoming article in our flexibility series.)

Note: Tenant-level elastic scaling is still limited by the physical resources available on a single node. When an "office" has no room for additional workstations and the node has no schedulable resources left, resources must be added at the infrastructure layer. This can be done in two ways. The first is cluster-level vertical scaling, such as upgrading to a larger cloud cluster specification or allocating more machine resources to the OceanBase process in an on-premises deployment. The second is horizontal scaling, such as adding physical nodes. We will cover cluster-level vertical and horizontal scaling in a later post.

Why Scaling Is Fast and Transparent

Traditional database scaling is slow and risky because it is essentially a physical-layer operation. In MySQL, for example, scaling requires provisioning a higher-specification server as a standby node, waiting hours for data replication to complete, and then performing a primary-standby switchover, which can briefly interrupt active client connections.

In contrast, OceanBase's tenant-level scaling is essentially a logical change in resource scheduling. When adjusting a unit config, the system only needs to perform basic resource availability checks and update the quota online.

This process involves no machine replacement, no data migration, and no primary-standby switchover, so the entire operation completes in seconds. Existing database connections remain active, and applications require no code modifications or schema changes.

Because OceanBase avoids time-consuming physical operations, operations teams can scale resources up or down at any time of day without waiting for a late-night maintenance window.

Case Study: How POP MART Handles Launch-Day Traffic Spikes

How does scaling that takes effect in seconds hold up under extreme, real-world workloads? POP MART's online blind box business, where users purchase randomized collectible figures, provides a clear example.

In the past, whenever POP MART released a popular new product, the platform would see nearly one million concurrent users. To handle these sudden traffic spikes, the operations team had to pre-provision expensive, oversized database instances late the night before the launch, and then stay up late again after the rush to scale them back down. This approach not only wasted resources but also placed heavy pressure on the operations team, especially because of the frequent late-night changes.

After migrating to OceanBase and consolidating dozens of isolated database instances into three multi-tenant clusters, their operational model changed completely:

Now, on product launch days, administrators simply scale up tenant resource quotas online during the day and scale them back down with a single click once the peak passes. According to public data, their database scaling time was cut by 90%. Without any application-level modifications, the system achieved 99.999% service continuity during high-concurrency product launches. For most medium-scale traffic fluctuations, the team can now easily handle the load simply by "adding workstations" to the existing tenants.

What Changes for Operations Teams

OceanBase's tenant-level elastic scaling shifts database capacity management from "late-night maintenance with service risk" to "anytime online adjustment." With no hardware replacement, no failover, and no application changes, OceanBase enables enterprises to adjust capacity safely during business hours and respond to traffic volatility with greater confidence.

As workloads continue to grow, tenant-level scaling may eventually reach the physical limits of a single machine. At that point, higher-level scaling capabilities become necessary, such as cluster-level horizontal scaling and machine specification upgrades. We will explore these topics in future articles.

Further Reading

• Introduction to OceanBase tenants
• Introduction to scaling in and out
• OceanBase Database Documentation