All Products
Search
Document Center

PolarDB:Limits on database development

Last Updated:Mar 28, 2026

PolarDB-X is highly compatible with the MySQL protocol and SQL syntax. Because PolarDB-X is a distributed database, some MySQL features behave differently or are not supported. Review these limits before you start development or migrate an existing application.

Limits on common identifiers

IdentifierMaximum lengthAllowed characters
Database32Uppercase and lowercase letters, digits, and underscores (_)
Sequence128Unicode characters
Partition16
Table64
Column
Partition key
View
Variables
Constraint

Limits on resource usage

Logical resources

ResourceLimit
Databases per cluster32
Tables per database8,192
Partitions per table8,192
Columns per table1,017
Sequences per database16,384
Views per database8,192
Global indexes per table32
Users per database2,048 (username: 255 characters maximum)

Physical resources

ResourceDefault limit
Connections per compute node20,000
Compute nodes added at a time99. To add more nodes at a time, contact Alibaba Cloud technical support.
Storage nodes added at a time

Limits on SQL syntax

Some limits are architectural constraints of distributed systems. Others are planned for future releases.

Unsupported features

The following MySQL features are not supported in PolarDB-X.

Custom operations

FeatureNotes
Custom data typeNot supported
TriggerNot supported

DDL

StatementNotes
CREATE TABLE ... LIKE ...Partitioned tables are not supported
CREATE TABLE ... SELECT ...Partitioned tables are not supported
MERGE, SPLIT, ADD, and DROP on subpartition tablesNot supported
MERGE, SPLIT, ADD, and DROP on partitioned index tablesNot supported

DML

StatementNotes
STRAIGHT_JOINNot supported
NATURAL JOINNot supported
INSERT DELAYEDNot supported
Variable references and operations (for example, SET @c=1, @d=@c+1; SELECT @c, @d)Not supported
LOAD XMLNot supported

DQL

StatementNotes
Subqueries in a HAVING clauseNot supported
Subqueries in a JOIN ... ON clauseNot supported

Database management

StatementNotes
SHOW WARNINGSThe LIMIT and COUNT combination is not supported
SHOW ERRORSThe LIMIT and COUNT combination is not supported
HELPNot supported

Operators

OperatorNotes
:=Not supported

Functions

FunctionNotes
Full-text search functionsNot supported
XML functionsNot supported
Functions for global transaction identifiersNot supported

Data types

TypeNotes
Spatial data types (GEOMETRY, LINESTRING)Not supported
JSON data typeSupported, but cannot be used as a partition key

Keywords

KeywordNotes
MILLISECONDNot supported
MICROSECONDNot supported

Supported features

The following custom operations and DDL statements are supported:

FeatureNotes
User-defined functionSupported
Stored procedureSupported
CursorSupported
ViewSupported
CREATE TABLE ... Generated Column ...Supported
RENAME TABLESupported
ALTER TABLESupported
Foreign keySupported
Subquery as scalar operandSupported

Behavior differences from MySQL

The following statements are supported but behave differently from standard MySQL.

UPDATE with ON UPDATE CURRENT_TIMESTAMP

In PolarDB-X, every logical UPDATE sets a column with the ON UPDATE CURRENT_TIMESTAMP attribute to the current timestamp, regardless of whether any other column changed. In MySQL, the column is only updated if at least one other column changes.

Example

-- Create a table with an ON UPDATE CURRENT_TIMESTAMP column
CREATE TABLE t (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

INSERT INTO t VALUES (1, 'Alice', NOW());

-- Update with no actual data change
UPDATE t SET name = 'Alice' WHERE id = 1;

-- PolarDB-X: updated_at is refreshed to CURRENT_TIMESTAMP
-- MySQL:      updated_at is NOT refreshed (no data changed)
SELECT id, name, updated_at FROM t WHERE id = 1;

If your application logic relies on MySQL's behavior of leaving updated_at unchanged when no data changes, update your queries or application code before migrating to PolarDB-X.