All Products
Search
Document Center

PolarDB:Enable X-Engine

Last Updated:Mar 28, 2026

X-Engine is a storage engine optimized for warm data. It uses an LSM-tree architecture to reduce storage costs compared to InnoDB, making it well-suited for data that is still accessed or updated but less frequently than hot data.

Prerequisites

Before you begin, make sure your cluster meets all of the following requirements:

  • The revision version is 8.0.1.1.31 or later, or 8.0.2.2.12 or later. To check the version, see Query an engine version.

  • The cluster is not a Multi-master Cluster (Limitless) Edition. X-Engine is not supported for this edition.

  • The primary node has at least 8 GB of memory. Read-only node specifications must be equal to or higher than the primary node.

  • The cluster has not joined a Global Database Network (GDN).

Limitations

Feature limitations

X-Engine does not support all InnoDB features. Any feature not listed in the following table behaves the same as in InnoDB.

CategoryFeatureBehavior
SQLForeign keysNot supported
SQLTemporary tablesNot supported
SQLGenerated columnsNot supported
SQLHandler APINot supported
Column propertiesMaximum column length (longblob, longtext, json)32 MB
GIS data typesGEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEMOMETRYCOLLECTIONNot supported
IndexesHash indexesNot supported
IndexesSpatial indexes and full-text indexesNot supported
TransactionsSupported isolation levelsRead Committed (RC) and Repeatable Read (RR) only
TransactionsMaximum data per transaction32 MB
TransactionsSavepointsNot supported
TransactionsXA transactionsInternal XA transactions only
LocksSupported lock granularitiesTable-level and row-level locks (gap locks not supported)
LocksSKIP LOCKEDNot supported
LocksNOWAITNot supported
Character setsNon-indexed columnsAll character sets
Character setsIndexed columnsLatin1 (latin1_bin), GBK (gbk_chinese_ci, gbk_bin), UTF-8 (utf8_general_ci, utf8_bin), UTF-8MB4 (utf8mb4_0900_ai_ci, utf8mb4_general_ci, utf8mb4_bin)
ReplicationBinary log formatsstmt, row, and mixed. The default format is row.
Note

The stmt and mixed binary log formats may cause data security issues in certain concurrent-write scenarios. Use the row format for write-heavy workloads.

Large-transaction limitations

X-Engine does not support large transactions. When a transaction modifies 10,000 or more rows, X-Engine automatically triggers the commit in middle mechanism, which internally commits the data in batches and starts sub-transactions to continue. This behavior does not guarantee transaction atomicity.

Important

The commit in middle mechanism does not produce an error. It silently changes transaction semantics. Design your application to avoid transactions that modify 10,000 or more rows in a single operation.

The following examples show how commit in middle affects different operations.

Partial rollback after large inserts

If a large INSERT transaction triggers commit in middle, the committed rows cannot be rolled back. Only the remaining uncommitted rows are rolled back.

DROP TABLE t1;
CREATE TABLE t1(c1 int primary key, c2 int) ENGINE=xengine;
BEGIN;
CALL insert_data(12000); -- Inserts 12,000 rows; commit in middle commits the first 10,000
ROLLBACK;               -- Only the last 2,000 rows are rolled back
SELECT COUNT(*) FROM t1;

Expected output:

+----------+
| COUNT(*) |
+----------+
|    10000 |
+----------+
1 row in set (0.00 sec)

DELETE cannot read rows committed mid-transaction

If DELETE is preceded by INSERT in the same large transaction, the commit in middle mechanism may cause the DELETE to miss newly committed rows.

DROP TABLE t1;
CREATE TABLE t1(c1 int primary key, c2 int) ENGINE=xengine;
CALL insert_data(10000);
BEGIN;
INSERT INTO t1 VALUES(10001, 10001), (10002, 10002);
DELETE FROM t1 WHERE c1 >= 0; -- Triggers commit in middle; the two inserted rows are not deleted
COMMIT;
SELECT * FROM t1;

Expected output:

+-------+-------+
| c1    | c2    |
+-------+-------+
| 10001 | 10001 |
| 10002 | 10002 |
+-------+-------+
2 rows in set (0.00 sec)

Usage notes

  • Enabling X-Engine triggers an automatic cluster restart. Expect approximately 30 seconds of connection interruption. Enable X-Engine during off-peak hours and make sure your application supports automatic reconnection.

  • After enabling, X-Engine cannot be disabled.

  • After enabling, the cluster cannot join a GDN.

Enable X-Engine

Choose one of the following methods based on whether your cluster already exists.

Method 1: Enable X-Engine on an existing cluster

  1. Log on to the PolarDB console. In the left-side navigation pane, click Clusters. Select a region and click the cluster ID to open the Basic Information page.

  2. In the left-side navigation pane, choose Settings and Management > Data Lifecycle. Click the X-Engine (Warm Data) tab, then click Enable.

    Note

    If the X-Engine (Warm Data) tab is not visible, verify that your cluster meets all prerequisites listed above.

    image

  3. In the Set X-Engine Proportion dialog box, set the memory and storage proportion for X-Engine based on your workload, then click Enable Now. Use the following table to choose a starting proportion:

    ScenarioInnoDB (%)X-Engine (%)
    Mostly hot data with infrequently accessed cold data8020
    Mix of hot data and cold data that is still updated and queried5050
    Small amount of hot data with large amounts of warm data to update or query2080
    Note

    X-Engine (%) must be between 10% and 90%. If all tables use X-Engine, set X-Engine (%) to 90%. After enabling, adjust the proportion on the X-Engine (Warm Data) tab under Settings and Management > Data Lifecycle.

Method 2: Enable X-Engine when purchasing a cluster

To enable X-Engine on a new cluster, set the Storage Engine parameter to InnoDB & X-Engine and configure the X-Engine (%) value during cluster purchase. For details, see the Storage Engine parameter in Purchase clusters.

imageimage
Note

After the cluster is created, adjust the proportion on the X-Engine (Warm Data) tab under Settings and Management > Data Lifecycle.

What's next