Meet OceanBase AI Lakebase, the unified database for operational data, real-time analytics, and AI.

Meet OceanBase AI Lakebase, the unified database for operational data, real-time analytics, and AI. Explore ->

Start on Cloud

OceanBase

A unified distributed database ready for your transactional, analytical, and AI workloads.

Product Overview

DEPLOY YOUR WAY

OceanBase Cloud

The best way to deploy and scale OceanBase

OceanBase Enterprise

Run and manage OceanBase on your infra

TRY OPEN SOURCE

OceanBase Community Edition

The free, open-source distributed database

OceanBase seekdb

Open source AI native search database

Customer Stories

Real-world success stories from enterprises across diverse industries.

View All

BY USE CASES

Mission-Critical Transactions

Global & Multicloud Application

Elastic Scaling for Peak Traffic

Real-time Analytics

Active Geo-redundancy

Database Consolidation

Comprehensive knowledge hub for OceanBase.

Blog

Live Demos

Training & Certification

Documentation

Official technical guides, tutorials, API references, and manuals for all OceanBase products.

View All

PRODUCTS

OceanBase Cloud

OceanBase Database

Tools Connectors and Middleware

QUICK START

OceanBase Cloud OceanBase Database

BEST PRACTICES

Practical guides for utilizing OceanBase more effectively and conveniently

Learn more about OceanBase – our company, partnerships, and trust and security initiatives.

About OceanBase

Partner

Trust Center

Document Feedback

Upgrade overview

Last Updated：2026-09-03 07:31:11 Updated

OceanBase clusters support cluster upgrade using upgrade scripts. The entire upgrade process is transparent to applications; applications do not need to stop writes or services in coordination with the server. OceanBase clusters are upgraded in the order of zones. During the upgrade, partition leaders will perform leader switchover across zones and divert traffic from the zone being upgraded to other zones for execution.

This topic describes the upgrade limitations, considerations, and paths for OceanBase Database.

Upgrade limitations

When upgrading an OceanBase cluster, note the following limitations:

DDL is prohibited: DDL is prohibited during certain stages of the upgrade and will be automatically re-enabled after the upgrade is complete.
Major freeze is prohibited: Major compaction is prohibited during upgrades between some versions and will be automatically re-enabled after the upgrade is complete.
Migration replication and load balancing are prohibited: Migration replication and load balancing are prohibited during upgrades between some versions.
Physical backup and recovery are prohibited: No physical baseline backup (log archiving continues) or physical recovery is initiated during cluster upgrade.
Creating new tenants is prohibited.

Notice

If an OceanBase cluster is associated with an arbitration service, ensure to upgrade the arbitration service version before upgrading the OceanBase cluster version. For details on upgrading the arbitration service version, see Upgrade an arbitration service.
You can use the system tenant to query the view oceanbase.DBA_OB_ARBITRATION_SERVICE to check if this OceanBase cluster is associated with an arbitration service.

Considerations

When upgrading an OceanBase cluster, consider the following points:

Log archiving is stopped during the upgrade from OceanBase Database V4.0 to V4.1.
If ADD SERVER/DELETE SERVER operations are required during the upgrade, contact technical support.
OceanBase transitional versions cannot be directly upgraded; refer to the upgrade version sequence in the oceanbase_upgrade_dep.yml file.
Upgrade scripts must be executed by directly connecting to the observer process where the Root Service resides; connections through OceanBase Database Proxy (ODP) are not supported.
The following parameters may change during the upgrade. Back up these parameters before the upgrade:
Starting from V4.3.0 Beta, OceanBase Database no longer supports the zlib_1.0 compression algorithm. The following pre-checks are performed during the upgrade:
- During the upgrade, using the zlib compression algorithm as the value of the log_transport_compress_func parameter is no longer supported. Please use another compression algorithm instead of zlib.
- During the upgrade, if tables are found using the zlib compression algorithm, replace the compression algorithm in those tables with another supported one, or disable compression during the upgrade.
- During the upgrade, using zlib as the compression algorithm for OBKV-Table connections is not allowed. Please select another compression algorithm by setting the tableapi_transport_compress_func parameter.
When a cluster running an earlier V4.3.x version is upgraded to V4.3.3 or later, for standby tenants, the lower-version cluster cannot parse logs generated by the higher-version cluster. An error will be reported when the standby tenant tries to commit logs (only an error is reported; the corresponding logs are not persisted). For details on data recovery, see Prepare for recovery.
Tenant backups made in a V4.3.2 cluster cannot be restored in a V4.3.3 cluster.
A cluster restored from a V4.3.2 backup cannot be upgraded to V4.3.3.
When upgrading to V4.4.2, if the pre-upgrade check reports the following error:
```
tenant has sys table with progressive_merge_round=1: tenant_id xxx table_ids 'xxx'
```
- If you are currently on V4.2.5 BP7, you must first upgrade to V4.2.5 BP7 hotfix3 or later, and then upgrade to V4.4.2.
- If you are currently on V4.3.5 BP2 or earlier, encountering this issue during the upgrade indicates that the upgrade is not currently supported.

Upgrade instructions

We recommend upgrading to V4.4.2 BP2 using the following path:

V4.4.2 and V4.4.2 BP1 can be directly upgraded to V4.4.2 BP2.
V4.4.0, V4.4.0 BP1, and V4.4.1 can be directly upgraded to V4.4.2 BP2.
V4.3.5 and V4.3.5 BP1 to BP5 require stopping at V4.3.5 BP6 before upgrading to V4.4.2 BP2.
V4.2.5 and V4.2.5 BP1 to BP6 require stopping at V4.2.5 BP7 before upgrading to V4.4.2 BP2.

Upgrade roadmap

4257-4356-4422-501

Note

This upgrade roadmap is for reference only. For more information about upgrade paths for different versions, refer to the oceanbase_upgrade_dep.yml file, which records the version upgrade topology of OceanBase.
After decompressing the target version's OceanBase RPM package, two directories named home and use are generated in the directory where the RPM package is stored. Upgrade-related scripts and the oceanbase_upgrade_dep.yml file are stored in the home/admin/oceanbase/etc directory.

For detailed information about the upgrade path confirmed using the oceanbase_upgrade_dep.yml file, see the Step 2: Confirm the upgrade process section in Upgrade an OceanBase cluster.

The meanings of the upgrade roadmap are as follows:

Path for V4.2.x versions:
- V4.0.0.0, V4.1.0.0 - V4.1.0.2, and V4.2.0.0 can be upgraded to V4.2.1.11, and then to V4.2.5.7.
- V4.2.2 - V4.2.4 can be directly upgraded to V4.2.5.7, or first upgraded to V4.2.5.0 - V4.2.5.6, and then to V4.2.5.7.
- V4.2.5 BP7 can be directly upgraded to V4.4.2 or V4.4.2.1.
- Barrier versions: V4.2.1.11, V4.2.5.7.
Upgrade path for V4.3.x versions:
- All V4.3.x versions can be directly upgraded to V4.3.5.6.
- V4.3.5.6 can be upgraded to V4.4.2.1.
- Upgrading from the V4.2.x series or lower versions to V4.3.x is not currently supported.
- Barrier version: V4.3.5.6.
Upgrade path for V4.4.x versions:
- V4.4.0 and V4.4.1 can be directly upgraded to V4.4.2 or V4.4.2.1/2.
- V4.4.0 and V4.4.1 can be directly upgraded to V4.6.0.0.
Upgrade path for V5.x versions:
- V4.6.0.0 can be upgraded to V5.0.1.

What to do next

Upgrade an OceanBase cluster

References

For information about how to upgrade an OceanBase cluster by using OceanBase Cloud Platform (OCP), see Upgrade version

Previous topic

Recommended configurations

Last

Next topic

Upgrade an arbitration service