We recommend migrating to a managed cluster instead of manually creating and dropping replicas.

CREATE CLUSTER REPLICA provisions a new replica of a cluster.

Conceptual framework

A cluster consists of zero or more replicas. Each replica of a cluster is a pool of compute resources that performs exactly the same computations on exactly the same data.

Using multiple replicas of a cluster facilitates fault tolerance. Clusters with multiple replicas can tolerate failures of the underlying hardware or network. As long as one replica remains reachable, the cluster as a whole remains available.


CREATE CLUSTER REPLICA cluster_name . replica_name option = value ,
Field Use
cluster_name The cluster you want to attach a replica to.
replica_name A name for this replica.


Field Value Description
SIZE text The size of the replica. For valid sizes, see Size.
AVAILABILITY ZONE text The availability zone of the underlying clodu provider in which to provision the replica. You must specify an AWS availability zone ID in either us-east-1 or eu-west-1, e.g. use1-az1. Note that you must use the zone’s ID, not its name.
INTROSPECTION INTERVAL interval The interval at which to collect introspection data. See Troubleshooting for details about introspection data. The special value 0 entirely disables the gathering of introspection data.
Default: 1s
INTROSPECTION DEBUGGING bool Whether to introspect the gathering of the introspection data.
Default: FALSE
IDLE ARRANGEMENT MERGE EFFORT integer Unstable. This option may be changed or removed at any time.
The amount of effort the replica should exert on compacting arrangements during idle periods.
DISK bool Private preview. This option has known performance or stability issues and is under active development.
Whether to attach a disk to the replica. See Disk for details.
Default: FALSE



The SIZE option for replicas is identical to the SIZE option for clusters option, except that the size applies only to the new replica.


PREVIEW This feature is in private preview. It has known performance or stability issues and is under active development. It isn't subject to our backwards compatibility guarantees.

You must contact us to enable this feature in your Materialize region.

Pricing for this feature is likely to change.

Replicas with disks currently consume credits at the same rate as replicas without disks. In the future, replicas with disks will likely consume credits at a faster rate than replicas without disks.

The DISK option for replicas works identically to the DISK option for clusters, except that the disk is attached only to the new replica.

Credit usage

The replica will consume credits at a rate determined by its size:

Size Credits per hour
3xsmall 0.25
2xsmall 0.5
xsmall 1
small 2
medium 4
large 8
xlarge 16
2xlarge 32
3xlarge 64
4xlarge 128
5xlarge 256
6xlarge 512

Credit usage is measured at a one second granularity. Credit usage begins when a CREATE CLUSTER REPLICA provisions the replica and ends when a DROP CLUSTER REPLICA statement deprovisions the replica.

Homogeneous vs. heterogeneous hardware provisioning

Because Materialize uses active replication, all replicas will be instructed to do the same work, irrespective of their resource allocation.

For the most stable performance, we recommend using the same size and disk configuration for all replicas.

However, it is possible to use different replica configurations in the same cluster. In these cases, the replicas with less resources will likely be continually burdened with a backlog of work. If all of the faster replicas become unreachable, the system might experience delays in replying to requests while the slower replicas catch up to the last known time that the faster machines had computed.




The privileges required to execute this statement are:

  • Ownership of cluster_name.
Back to top ↑