TechPrufer
Sign inGet started

Blogs›SingleStore›Online AZ Migration

Online AZ Migration

Online AZ Migration

1
posts
2026

SingleStore's third generation cluster architecture introduces a zero-copy data fabric that allows compute clusters to attach to any database without data duplication. This enables direct support for Apache Iceberg, facilitating agentic applications by allowing read, write, and reasoning operations on open data formats. Features like Smart Read Replicas, Database Branching, and Smart DR leverage this fabric for independent scaling, rapid environment creation, and efficient disaster recovery, all while enabling Online AZ Migration, allowing customers to reconfigure a running deployment between single-AZ and multi-AZ operation without taking applications offline or migrating databases. This capability is possible because the database is built around independently managed partitions rather than a single machine that owns the entire dataset. If a leaf node becomes unavailable, the distributed query engine simply redirects work to healthy replicas for the affected partitions. The remainder of the query plan continues executing normally across the rest of the cluster. SingleStore refers to this capability as leaf fanout failover. Recovery occurs at partition granularity instead of server granularity, allowing failures to be isolated to a much smaller portion of the system.

2026

Scaling Database Availability Without Disruptio

7/21/2026

Introduces Online AZ Migration, a capability allowing customers to reconfigure a running SingleStore deployment between single-AZ and multi-AZ operation without taking applications offline or migrating databases. This is enabled by the distributed SQL architecture where data is partitioned and ownership is distributed across an entire cluster, allowing for partition-level failover and redistribution of replicas online. The post details how this contrasts with traditional databases that have a single primary instance and how SingleStore's partition-based approach allows for dynamic infrastructure evolution without architectural changes to the database itself.