PolarDB-X supports two database modes: AUTO mode and DRDS mode. AUTO mode is the modern default for new applications, offering automatic partitioning, elastic scaling, and richer partition management. DRDS mode is the legacy sharding model, preserved for compatibility with applications migrated from older PolarDB-X versions.
For new applications, use AUTO mode. If you are migrating from PolarDB-X 1.0, AUTO mode is also the recommended target.
How it works
When you create a PolarDB-X database, the MODE parameter determines how tables are partitioned:
-
AUTO mode — Tables are partitioned tables. PolarDB-X automatically selects a partition key and distributes data evenly across partitions using a range-based consistent hashing algorithm. Standard MySQL
CREATE TABLEsyntax works without modification. Available in PolarDB-X V5.4.13 and later. -
DRDS mode — Tables are sharded tables. You specify a database shard key and a table shard key using PolarDB-X-specific sharding syntax. If no shard key is specified, a non-partitioned table is created. This is the default when you omit
MODEfromCREATE DATABASE.
A single PolarDB-X instance can contain databases in both modes.
Usage notes
-
Specify
MODE='AUTO'inCREATE DATABASEto create a database in AUTO mode. -
If
MODEis omitted, a DRDS mode database is created. -
After a database is created, its mode cannot be changed.
-
AUTO mode databases cannot be created in PolarDB-X clusters of the standard edition.
-
In AUTO mode databases, use standard MySQL partitioning syntax only — DRDS sharding syntax is not supported.
-
In DRDS mode databases, use DRDS sharding syntax only — MySQL partitioning syntax is not supported.
Create a database
Use the MODE parameter to set the database mode at creation time.
MODE value |
Database mode | Default? | Table syntax |
|---|---|---|---|
'AUTO' |
AUTO mode | No | Standard MySQL CREATE TABLE; creates partitioned tables |
'DRDS' |
DRDS mode | Yes | PolarDB-X sharding syntax; creates sharded tables |
AUTO mode:
CREATE DATABASE auto_db MODE='AUTO';
Tables created in this database are partitioned tables. See CREATE TABLE (AUTO mode) and CREATE DATABASE.
DRDS mode:
-- Either form creates a DRDS mode database
CREATE DATABASE drds_db MODE='DRDS';
CREATE DATABASE drds_db;
Tables created in this database are sharded tables. See CREATE TABLE (DRDS mode) and CREATE DATABASE.
Partition tables in AUTO mode
AUTO mode supports both automatic and manual partitioning.
Automatic partitioning
Run a standard CREATE TABLE statement without specifying any partitioning clause. PolarDB-X selects the partition key and horizontally partitions both the table and its indexes.
CREATE TABLE tb (a INT, b INT, PRIMARY KEY(a));
In AUTO mode, PolarDB-X automatically partitions this table by primary key:
SHOW FULL CREATE TABLE tb\G
*************************** 1. row ***************************
TABLE: tb
CREATE TABLE: CREATE PARTITION TABLE `tb` (
`a` int(11) NOT NULL,
`b` int(11) DEFAULT NULL,
PRIMARY KEY (`a`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4
PARTITION BY KEY(`a`)
PARTITIONS 16
1 row in set (0.01 sec)
The same statement on a DRDS mode database creates a non-partitioned table instead.
Manual partitioning
Specify the partition key and policy explicitly. AUTO mode supports hash, key, range, range columns, list, and list columns partitioning — using standard MySQL syntax.
-- Hash partitioning with 4 partitions
CREATE TABLE tb (a INT, b INT, PRIMARY KEY(a))
PARTITION BY HASH(a) PARTITIONS 4;
Shard tables in DRDS mode
DRDS mode uses PolarDB-X-specific sharding syntax with DBPARTITION BY and TBPARTITION BY. Only hash-based sharding is supported.
CREATE TABLE tb (a INT, b INT, PRIMARY KEY(a))
DBPARTITION BY HASH(a)
TBPARTITION BY HASH(a)
TBPARTITIONS 4;
Routing algorithms
The key difference between the two modes is how data is routed to partitions.
AUTO mode: consistent hashing
AUTO mode uses a range-based consistent hashing algorithm.
Advantages:
-
Supports partition splitting, merging, and migration without recalculating all hash values.
-
Enables hot data splitting: hot partitions can be split into multiple partitions and redistributed across data nodes.
-
Partition pruning works on prefix conditions, calculation expressions (
pk = POW(2, 4)), and collation-aware comparisons. -
Join operation pushdown is maintained during partition splits, merges, and migrations.
Limitations:
-
The consistent hashing algorithm is more computationally complex than modulo hashing, which can slightly reduce throughput on point-select workloads. In practice, queries per second (QPS) is comparable to DRDS mode for
oltp_point_selectqueries (see Performance benchmark).
DRDS mode: modulo hashing
DRDS mode routes data using modulo operations on hash values against the number of physical table shards.
Advantages:
-
Simple, low-overhead routing algorithm.
Limitations:
-
Changing the shard count requires recalculating hash values for all data. For example, scaling from 4 to 5 shards triggers a full data rehash.
-
No partition splitting for hot data — hot shards cannot be subdivided.
-
Range and list partitioning are not supported.
Feature comparison
AUTO mode adds significant capabilities over DRDS mode. The table below covers the full feature set.
Tip: If you only need to know which mode to use, see the FAQ.
| Feature | AUTO mode | DRDS mode |
|---|---|---|
| Partitioning | ||
| Automatic partitioning (no partition key required) | Supported | Not supported |
| Hash and key partitioning | Supported (consistent hashing) | Supported (modulo) |
| Range and range columns partitioning | Supported | Not supported |
| List and list columns partitioning | Supported | Not supported |
| Vector partition key (multiple columns as partition key) | Supported | Not supported |
| Partition key collation | Supported | Not supported |
| Non-partitioned table and broadcast table | Supported | Supported |
| Distribution | ||
| Transparent distribution (default primary key partitioning) | Supported | Not supported |
| Default global secondary indexes (GSIs) | Supported — index tables auto-partitioned by index key columns | Not supported |
| Load balancing | Supported | Not supported |
| Hot data distribution | Supported | Not supported |
| Partition management | ||
| Partition creation, deletion, and modification | Supported | Not supported |
| Partition splitting and merging | Supported | Not supported |
| Partition migration | Supported | Not supported |
| Partition truncation | Supported | Not supported |
| Hot data partition analysis | Coming soon | Not supported |
| Table modification | ||
| Table type change (non-partitioned, broadcast, or partitioned) | Supported | Supported |
| Partition modification (count, key type, policy) | Supported | Supported |
| Auto scaling | ||
| Write interruption during scaling | No interruption | Brief interruption |
| Other DDL operations during scaling | Allowed | Not allowed |
| Compatible with auto scaling | Yes | No |
| Locality | ||
| Static storage isolation (databases, tables, partitions) | Supported | Supported (databases and tables only) |
| Dynamic storage isolation | Supported | Not supported |
| Partition pruning | ||
Prefix-based pruning (e.g., PARTITION BY KEY(a,b,c) with a=100) |
Supported | Not supported |
Constant folding in expressions (e.g., pk = POW(2, 4)) |
Supported | Not supported — partition key must be a constant |
| Collation-aware case sensitivity and trailing-space handling | Supported | Not supported |
| Other | ||
| Join operation pushdown | Supported (maintained during split/merge/migrate) | Supported |
Partition selection (SELECT * FROM tb PARTITION (p1)) |
Supported | Not supported |
| Time to live (TTL) | Supported | Not supported |
AUTO_INCREMENT |
Globally unique, monotonically increasing, and consecutive | Globally unique; may not be monotonically increasing or consecutive |
Performance benchmark
Sysbench benchmark tests comparing AUTO mode (partitioned tables) and DRDS mode (sharded tables) at the same scale.
Test environment:
-
Instance type:
polarx.x4.2xlarge.2e -
Compute nodes (CN): 16C64G × 2
-
Data nodes (DN): 16C64G × 2
-
Version: 5.4.13-16415631
Test data:
| Setting | AUTO mode (partitioned) | DRDS mode (sharded) |
|---|---|---|
| Partition / shard count | 32 partitions | 32 physical table shards |
| Partitioning clause | PARTITION BY HASH(id) PARTITIONS 32 |
DBPARTITION BY HASH(id) TBPARTITION BY HASH(id) TBPARTITION 2 |
| Data volume | 160 million rows | 160 million rows |
Test scenarios:
-
oltp_point_select— equality-condition point reads using the partition key -
oltp_read_only— point reads and small-range reads in a transaction using the partition key -
oltp_read_write— point and small-range reads and writes using the partition key
Results:
-
oltp_point_select: QPS for partitioned tables is comparable to sharded tables. The consistent hashing algorithm is more complex than modulo hashing, but the difference is negligible for point lookups. -
oltp_read_onlyandoltp_read_write: QPS for partitioned tables is approximately 33% higher than for sharded tables, because partition pruning is triggered for small-range queries.
FAQ
When should I use AUTO mode versus DRDS mode?
Use AUTO mode. It is available in PolarDB-X V5.4.13 and later and supports all modern distributed database features. If your application is migrating from PolarDB-X 1.0, AUTO mode is the only supported target mode.
Should I use automatic or manual partitioning in AUTO mode?
Start with automatic partitioning — it works with standard CREATE TABLE syntax and requires no upfront partition planning. Once you have real query patterns, run ALTER PARTITION to tune partition keys and counts if needed. Switch to manual partitioning upfront only if you already know the SQL access patterns and join relationships for your tables.
How many partitions does automatic partitioning create?
The default partition count is calculated as: number of nodes specified at instance creation × 8. For a 2-node instance, automatic partitioning creates 16 partitions. This count does not change when you add nodes later.
To change the default for new tables, modify the AUTO_PARTITION_PARTITIONS parameter. This affects all new tables in the instance. Existing tables are not changed.
If new tables are created with a different partition count than existing tables, join operations between them cannot be pushed down, which reduces query performance. Set partition counts consistently across related tables.
Can I change the partition count of an existing auto-partitioned table?
Yes. To change the partition count for new auto-partitioned tables, modify the AUTO_PARTITION_PARTITIONS parameter for the instance. This change applies to all new tables created after the modification. See Use ALTER TABLE to modify table partitions (AUTO mode).
How do I convert a DRDS mode database to AUTO mode?
Choose based on your PolarDB-X version. Check your version first: see View the version of an instance.
-
V5.4.16 and later (recommended): Use
CREATE DATABASE LIKEorCREATE DATABASE ASto convert the database. See Convert a database in DRDS mode to a database in AUTO mode. -
All versions — DTS migration: Create an AUTO mode database and tables in the target instance, then use Data Transmission Service (DTS) to migrate data from the DRDS mode source.
-
All versions — dump and restore: Use
mysqldumpto export data from the DRDS mode database (excludingCREATE TABLEstatements). Create an AUTO mode database with the target schema, then import the dump using thesourcecommand.