Release Notes for MariaDB Xpand 9.3 Beta 7

MariaDB Xpand is a distributed storage engine. Xpand provides High Availability (HA), full ACID compliance, and fault tolerance with scale-out and elasticity. Through Xpand, MariaDB Enterprise Server harnesses the power of distributed SQL, with data distributed across Xpand nodes and queries executed across Xpand nodes as needed to produce a result set.

MariaDB Xpand 9.3-Beta-7 is included with MariaDB Enterprise Server 10.5.4-2. This release of Xpand is beta maturity, and is not recommended for production use. Subsequent releases in the Xpand 9.3 series will focus on stability and reliability.

MariaDB Xpand 9.3-Beta-7 was released on 2020-07-16.

High Availability (HA)

Each table created using the Xpand engine is split into slices, which are distributed across Xpand nodes in the Xpand distributed SQL layer. Data slices are replicated to ensure at least two copies of each slice exist. The number of copies can be set on a per-table basis, with the recommended minimum and default of 2. For smaller tables that are frequently used in JOIN, query performance can be improved by designating the table ALLNODES, to ensure presence on all nodes.


Xpand clusters can consist of very large node counts, relative to traditional Primary/Replica clusters, while remaining manageable. The minimum required number of nodes in an Xpand cluster is 3, to ensure HA while avoiding split-brain scenarios. An Xpand distributed SQL layer can consist of tens, or even hundreds, of nodes for improved scalability and performance.

Fault Tolerance

Xpand has built-in fault tolerance, which runs in the background and is fully transparent to the user. Replication of Xpand data slices ensures that a single Xpand node crash does not impact data access. Upon an Xpand node crash, the Xpand cluster adapts to the new number of nodes, rebalancing slices to ensure the cluster has the configured level of redundancy, and remains fault tolerant. If the crashed Xpand node recovers, rebalancing will copy slices from other cluster nodes then return the recovered node to the cluster.

Adding and Removing Nodes

As your workload and capacity needs grow, nodes can be added to an existing Xpand cluster without outage or traffic impact. As a new node is added to the Xpand cluster, the rebalancer will copy slices from other Xpand nodes. As each slice becomes available, the new Xpand node will begin responding to queries.

An Xpand cluster can be decreased in size on-demand, for example when equipment reaches end of lifespan, equipment maintenance is required, or the need for temporarily-increased capacity abates. As an Xpand node is decommissioned, data slices are copied to other Xpand nodes. An Xpand node exits service when all slices have been redistributed. The cluster remains online throughout this process.

Known Issues/Limitations

  • In this release CREATE VIEW, CREATE FUNCTION, CREATE PROCEDURE are not automatically replicated to all Xpand nodes. Repeat on every node of the cluster, if needed.

  • Substitution of variables in query strings is not presently supported

  • Savepoints are not presently supported

  • RENAME TABLE should not be used, as it does not remove the old name

  • Some complex queries, those involving joins and window functions, CTEs, or cross-engine joins may produce a spurious table not found error message and fail to execute.

  • ALTER TABLE executed on one node will not immediately be reflected in the SHOW CREATE TABLE on other nodes. Using the layered table on the other nodes, however, does work. Under some circumstances the query may return an error message (table has changed), but it will run properly if re-submitted.