X-Engine is PolarDB's LSM tree-based storage engine, designed for write-heavy workloads where storage cost is a priority. If your data grows faster than your budget — large-scale archiving, append-heavy logs, warm data tiering — X-Engine reduces storage usage by up to 70% compared with InnoDB at no extra charge.
What is X-Engine?
X-Engine is a storage engine developed by Alibaba Cloud, built on log-structured merge-tree (LSM tree) architecture and the Zstandard (ZSTD) compression algorithm. Unlike InnoDB's B-tree structure, X-Engine optimizes for sequential writes and high compression, making it well-suited for archiving and append-heavy workloads.
For an overview of X-Engine features and architecture, see X-Engine.
Version requirements
X-Engine is supported on PolarDB for MySQL 8.0.1 and 8.0.2. MySQL 5.6 and 5.7 clusters do not support X-Engine.
Certain features require specific revision versions:
| Feature | Minimum revision version |
|---|---|
| Enable X-Engine on an existing cluster | 8.0.1.1.31 or later / 8.0.2.2.12 or later |
| Partitioned tables | 8.0.1.1.34 or later / 8.0.2.2.16 or later |
| Parallel queries | 8.0.1.1.34 or later (MySQL 8.0.1 only) |
| Query compression ratio via SQL | 8.0.1.1.40 or later / 8.0.2.2.22 or later (Enterprise Edition only) |
How much storage can X-Engine save?
Compared with InnoDB, X-Engine reduces storage usage by up to 70%, depending on your data type. Compression is enabled by default.
To check the estimated compression ratio for a specific table, run the following query. This example queries the compression ratio for the primary index of table test1 in database test:
SELECT
TABLE_NAME,
SUBTABLE_NAME,
SUM(EXTENTS*APRROX_CMP_RATIO)/SUM(EXTENTS)
FROM
INFORMATION_SCHEMA.XENGINE_SUBTABLE
WHERE TABLE_NAME = 'test.test1' AND SUBTABLE_NAME = 'PRIMARY' AND LEVEL in (1, 2);The query targets levels 1 and 2 because X-Engine organizes table data in LSM tree-based indexes, and most data resides at those levels. Level 0 holds data freshly flushed from memory and is not compressed. The result is a weighted average compression ratio across the two levels.
To query the compression ratio for a secondary index, replace 'PRIMARY' with the index name in the SUBTABLE_NAME filter.
XENGINE_SUBTABLE columns used in this query:
| Column | Description |
|---|---|
TABLE_NAME | Combined database and table name, in the format database.table (for example, test.test1) |
SUBTABLE_NAME | Index name |
LEVEL | Logical layer ID |
EXTENTS | Number of used extents |
NUM_ENTRIES | Current data volume |
NUM_DELETES | Deleted data volume |
APRROX_CMP_RATIO | Estimated sampling-based compression ratio |
SAMPLE_OUTDATED | Whether the sampled data is outdated |
This query requires an Enterprise Edition cluster running one of the following revision versions:
PolarDB for MySQL 8.0.1, revision 8.0.1.1.40 or later
PolarDB for MySQL 8.0.2, revision 8.0.2.2.22 or later
Why is the compression ratio low right after a bulk data import?
X-Engine uses background asynchronous compression — data is reorganized and compressed gradually without affecting running workloads. Most reorganization and compression operations happen during off-peak hours.
After a bulk import, the data appears close to its original uncompressed size. Storage space is released progressively as background compression completes.
What are the performance trade-offs?
X-Engine's LSM tree structure delivers stronger write performance than read performance. Because data compression is always on, X-Engine scores 10–20% lower than InnoDB in Sysbench benchmarks.
See Performance comparison between X-Engine Edition and Cluster Edition in PolarDB for MySQL 8.0.1 for detailed benchmark results.
How does X-Engine compare to RocksDB and TokuDB?
X-Engine achieves a similar compression ratio to RocksDB. TokuDB is deprecated, and all TokuDB data on Alibaba Cloud has been migrated to X-Engine.
Compared with RocksDB and MyRocks, X-Engine provides large-scale storage, high elasticity, and uninterrupted schema changes. See Benefits of X-Engine for the full comparison.
What are the advantages of PolarDB X-Engine over ApsaraDB RDS X-Engine?
PolarDB X-Engine runs on a compute-storage decoupled architecture with distributed storage. Key advantages:
Up to 500 TB of storage space
Read-only nodes can be added or released independently; up to 16 read-only nodes can share a single copy of data
High availability does not depend on binary logs, which improves write performance
How is X-Engine billed?
X-Engine uses the same billing model as InnoDB — no additional charges. You pay only for the storage space actually used after compression. For example, if your data is 100 GB in InnoDB and compresses to 30 GB in X-Engine, you are charged for 30 GB.
Does X-Engine have real-world production usage?
X-Engine is used within Alibaba Group and by Alibaba Cloud customers. PB-scale data across more than 3,000 clusters is stored in X-Engine. See Best practices for case studies.
What features does X-Engine support?
| Feature | Supported | Notes |
|---|---|---|
| Transactions | Yes | |
| Online DDL | Yes | Does not block concurrent transactions |
| Parallel DDL | Yes | |
| Row locks | Yes | Row-level concurrency control with deadlock detection, same as InnoDB |
| Large transactions | No | When a transaction modifies 10,000 or more rows, the commit in middle feature activates — X-Engine commits internally and starts a sub-transaction to continue |
| Partitioned tables | Yes | Requires revision 8.0.1.1.34 or later / 8.0.2.2.16 or later; currently in canary release phase |
| In-memory column index (IMCI) | No | |
| Hot/cold data separation on different storage media | No | |
| Parallel queries | Yes | Requires MySQL 8.0.1, revision 8.0.1.1.34 or later |
| Serverless | Conditional | Serverless can be enabled for fixed-spec clusters that already have X-Engine enabled (check minor version requirements); X-Engine cannot be enabled for serverless clusters |
What isolation levels does X-Engine support?
X-Engine supports read-committed and repeatable-read isolation. Read-committed is the default.
What are the limits of X-Engine?
As a MySQL storage engine, X-Engine supports only common MySQL features. See Limits for the full list.
How do I create a PolarDB cluster with X-Engine?
On the cluster purchase page in the PolarDB console, set Database Engine to MySQL 8.0.1 or MySQL 8.0.2, then set Storage Engine to InnoDB & X-Engine.
How do I enable X-Engine on an existing cluster?
Log on to the PolarDB console and click the target cluster ID.
In the left-side navigation pane, choose Settings and Management > Data Lifecycle.
On the X-Engine (Warm Data) tab, click Enable.
The cluster must run one of the following revision versions:
PolarDB for MySQL 8.0.1, revision 8.0.1.1.31 or later
PolarDB for MySQL 8.0.2, revision 8.0.2.2.12 or later
For version requirements and prerequisites, see Prerequisites.
How do I use X-Engine for a table?
Set ENGINE=xengine when creating a table. For existing tables, run an ALTER TABLE statement to change the storage engine. See Usage notes for syntax and limitations.
How do I adjust the X-Engine memory allocation?
Log on to the PolarDB console and click the target cluster ID.
Choose Settings and Management > Data Lifecycle.
On the X-Engine (Warm Data) tab, adjust the memory resource proportion.
See Adjust the proportion of memory resources for details.
How do I enable partitioned tables for X-Engine?
Partitioned tables for X-Engine are in the canary release phase. To apply:
Go to Quota Center.
Find the quota with ID
polardb_mysql_xengine_partition.Click Apply in the Actions column.
For setup guidance, join the DingTalk group (group ID: 24490017825) to get technical support.
How do I check storage space used by X-Engine tables?
Connect to your PolarDB cluster using the primary cluster endpoint, then run the following query. This example checks storage usage for table test1 in database test:
SELECT
SUM(TOTAL_EXTENT_COUNT)/512 AS SIZE_GB,
SUM(USED_EXTENT_COUNT)/512 AS USED_SIZE_GB,
SUM(FREE_EXTENT_COUNT)/512 AS FREE_SIZE_GB
FROM
INFORMATION_SCHEMA.XENGINE_TABLE_SPACE
WHERE TABLE_SPACE_ID IN (
SELECT TABLE_SPACE_ID
FROM INFORMATION_SCHEMA.XENGINE_SUBTABLE
WHERE TABLE_NAME = 'test.test1');Each extent is 2 MB. Dividing by 512 converts the extent count to gigabytes.
The query uses two system tables:
XENGINE_TABLE_SPACE — calculates storage size from physical files:
| Column | Description |
|---|---|
TABLE_SPACE_ID | Tablespace ID. Query XENGINE_SUBTABLE by table name to get this value. |
TOTAL_EXTENT_COUNT | Total number of extents |
USED_EXTENT_COUNT | Number of used extents |
FREE_EXTENT_COUNT | Number of available extents |
XENGINE_SUBTABLE — calculates storage size by LSM level:
| Column | Description |
|---|---|
TABLE_NAME | Combined database and table name, in the format database.table |
SUBTABLE_NAME | Index name |
SUBTABLE_ID | Index ID |
TABLE_SPACE_ID | Tablespace ID of the index |
LEVEL | Logical layer ID |
LAYER | Physical layer within the logical level. Level 0 can have multiple physical layers; levels 1 and 2 have one each. |
EXTENTS | Number of extents used at this logical level |