Vertical Scaling in OceanBase: Upgrade Node Capacity Without Database Downtime

Earlier in this Elastic Scaling series, we explained how OceanBase's native distributed architecture reduces the need for manual sharding at the database and table levels, and how OceanBase can respond to traffic fluctuations within seconds by adjusting tenant specifications. In OceanBase, a tenant is similar to a database instance and has its own resource quota. Adjusting tenant specifications reallocates CPU, memory, and other resources on existing machines. Because this operation does not involve replacing physical hardware, it can usually be performed without application-side changes.

However, tenant specification adjustment is still limited by the resources available on a single machine. When a tenant's quota approaches the capacity of a machine, or when further adjustment cannot meet workload requirements, the cluster needs to move to higher-spec machines. That move is vertical scaling.

OceanBase's Three-Tier Elastic Architecture

OceanBase's elastic scaling capabilities can be divided into three tiers, each corresponding to resource adjustment at a different level of granularity.

The first tier is tenant specification adjustment. As long as a node still has idle physical resources, the system can handle traffic peaks by adjusting a tenant's CPU and memory quotas. The change takes effect within seconds and does not require any machine replacement. This is the fastest and most cost-effective approach, and was covered in detail in the second article of this series.

The second tier is machine specification adjustment, or vertical scaling. When simply adjusting tenant specifications can no longer meet workload requirements, the physical machines in the cluster must be replaced with higher-spec machines — for example, upgrading nodes from 32 cores to 64 cores to handle larger traffic spikes driven by business growth. Unlike horizontal scaling, which "adds nodes," vertical scaling means replacing existing nodes with higher-spec nodes. The number of nodes in the cluster's logical topology remains unchanged.

For private deployments, physical servers are constrained by fixed hardware specifications. In practice, increasing single-node compute capacity involves the following process: add a new high-spec node → migrate data to the new node → take the old low-spec node offline.

On OceanBase Cloud, this sequence of node addition, data migration, and node removal is packaged into the Change Compute and Storage operation on the Change Instance Configurations page. When you trigger a specification upgrade in the cloud, you can choose between two paths based on your needs:

• The default, cross-machine path: this is the standard strategy. The system starts a new high-spec machine in the background, synchronizes data, and then smoothly replaces the old machine. In effect, it is an automated, integrated version of the "scale out first, then scale in" process used in private deployments.
• In-place scaling: for V4.x and later instances, you can choose to directly increase the CPU, memory, and storage allocated to the existing instance without interrupting database services. This method skips cross-machine data migration entirely. OceanBase's documentation does note two caveats: in-place scaling may introduce temporary latency and carries some stability risk, so it is best not to run it during peak hours.

The third tier is node-count adjustment, or horizontal scaling. When a single machine's compute and storage resources are exhausted, and the system needs to break through the single-machine limit so that overall read and write capacity can scale linearly with the number of nodes, additional cluster nodes are added. This will be covered in the final article of this series.

Why Machine Replacement Is Nearly Transparent to Applications

Replacing a physical machine with a larger one involves a large amount of cross-machine data synchronization and a machine switchover. Can application traffic really be switched over smoothly?

Take MySQL as an example. Scaling up machine specifications usually requires adding a larger standby server and synchronizing data through log replication. Machine-level data synchronization is not only time-consuming, but also prone to primary-standby replication lag. Once synchronization is complete, a primary-standby switchover must be performed. This switchover may cause a brief service interruption, during which connections can be dropped and requests may fail. As a result, it often has to be scheduled during off-peak hours, such as late at night.

When OceanBase performs vertical scaling by replacing machines, it also needs to add new machines. However, its internal mechanism is fundamentally different from MySQL's machine-level primary-standby replication.

In OceanBase Tenant-Level Scaling: Adjust Resources in Seconds, we used an analogy: a physical machine is like an office building in a business park, while the resource units, or units, allocated to a tenant are like the offices a company leases inside that building. The tenant specification expansion discussed in the previous article is like adding more desks and chairs to the same office, thereby gaining more resources without moving offices.

But when the entire office building is full and no more desks can be added, the tenant needs to move to a larger physical machine. At this point, OceanBase creates a larger resource unit on the new machine — the "new office building." It then migrates the replicas in the old unit to the new unit one by one, and finally takes the old unit offline, ending the lease on the old office. This is a smooth process of adding a new unit, migrating data, and removing the old unit.

The sequence involves two phases, data synchronization and traffic switchover, and OceanBase's native distributed architecture changes how each one behaves. Three mechanisms do the work.

1. Log-stream granularity instead of node-level replication

OceanBase synchronizes redo logs at the log stream (LS) level. A log stream carries the logs for the tablets a tenant holds on a given node, rather than covering everything on the machine the way MySQL's binlog does.

This finer granularity gives the system far more scheduling flexibility during synchronization, and avoids the performance bottleneck that arises in MySQL when it has to preserve a single global log order within a node. During the final leader switchover, the leader role moves log stream by log stream — one group of tablets at a time, rather than an entire machine in a single step — which also helps spread out the impact on the application and reduces the extent to which it notices the change.

2. Physical clog replication instead of binlog replay

MySQL primary-standby synchronization relies on logical logs, namely binlogs. After receiving these logs, the standby first writes them to relay logs and then performs logical replay. This creates a long processing chain with significant overhead.

OceanBase, by contrast, replicates physical redo logs, known as clogs (commit logs), through its Paxos-based log layer. These logs are smaller and cheaper to replay. Combined with log-stream-level synchronization, this allows the new node to quickly catch up with the old node, and avoids the common MySQL problem where primary-standby lag keeps growing rather than shrinking.

3. Smooth leader switchover

OceanBase replicates clogs with Multi-Paxos, and elects leaders through a lease-based election protocol of its own. Machine replacement then relies on smooth leader switchover, controlled by the enable_smooth_leader_switch parameter: the old leader replica does not step down until the transactions it has already committed are persisted on the target replica. It then proactively hands the leader role to the replica on the new node, without manual intervention.

OceanBase Database Proxy (ODP), the database proxy layer, refreshes its routing cache as soon as an OBServer reports a role mismatch, so subsequent application requests are forwarded to the new leader. Requests that arrive during the brief switchover window are retried transparently when they are single statements or run in autocommit mode; a statement inside an already-open explicit transaction is rolled back instead, so ordinary retry-safe transaction handling still applies on the application side. From the application's perspective, there is almost no noticeable interruption or error.

Performance During the Replacement

Service continuity is one question. Throughput and latency while the replacement is running are another.

• Will data migration compete with foreground workloads for resources?

Data synchronization runs as a background task, and OceanBase has built-in physical resource isolation that lets operations teams cap what those tasks consume. Enabling enable_global_background_resource_isolation together with global_background_cpu_quota bounds the CPU available to background work, and sys_bkgd_net_percentage limits the share of NIC bandwidth that migration traffic can take. This will be covered in more detail in the next article of this series, Horizontal Scaling.

• Will there be jitter during leader handover?

During the handover between old and new leaders, a small number of requests may arrive exactly at the transition point. As described above, these requests are retried by the proxy layer rather than failed. In addition, each leader serves only one log stream — a group of tablets, not the entire database — so the blast radius of any single handover stays small. From the application's perspective, individual requests may experience very slight response-time jitter during the brief handover window, but the overall service remains smooth.

Where Vertical Scaling Stops

When upgrading to higher-spec machines, OceanBase reduces service impact through its log-stream synchronization and smooth switchover mechanisms. This avoids the brief interruptions caused by traditional primary-standby switchovers, and allows resources to be adjusted on demand at any time, without relying on a fixed maintenance window.

In supported OceanBase Cloud environments, the upgrade can also be automatic. When workloads surge or traffic fluctuates frequently, you can scale resources on demand without manual intervention. After compute auto-scaling is enabled, the system continuously monitors node CPU utilization; when utilization crosses the configured threshold — 70% by default — for the configured share of an observation window, compute resources are doubled synchronously, repeating until the maximum specification you set is reached. One thing worth knowing before you enable it: the scale-up can cause second-level connection drops, so applications need automatic reconnection.

However, vertical scaling still has its limits. Once a single machine reaches its capacity limit, the system needs to move to the next stage of scaling. In the next article, we will explain how OceanBase achieves true horizontal scalability by adding nodes.

Further Reading

• Change instance configurations — OceanBase Cloud documentation for compute, storage, and node changes
• Set compute auto-scaling — thresholds, observation windows, and scale-up limits