• Start

Scaling

Resize SurrealDB Cloud instances and plan capacity for growing workloads.

As your data volume and query load grow, you scale SurrealDB Cloud to avoid throttling, high latency, or storage exhaustion. How you scale depends on your plan: Start instances grow vertically on one node, while Scale clusters grow horizontally on SurrealDS.

AspectStartScale
Growth modelLarger instance type on one nodeMore compute units (query nodes)
Fault toleranceSingle point of failure within the instanceMulti-node cluster; survives loss of one node
Operational modelSingle-node managed optionManaged cluster — no self-hosted Kubernetes or replication stack
Typical fitDev, staging, cost-sensitive productionBusiness-critical production, horizontal throughput

Move to Scale when a single node is no longer enough — because you need fault tolerance, sustained query throughput across nodes, or both — not only because disk is full. Scale runs a minimum of three compute units; see High availability for why that matters.

Vertical scaling means moving to a larger instance type with more CPU, memory, storage, or I/O on a single node. It is the default approach on the Start plan when metrics show sustained high utilisation on one instance.

Vertical scaling: a single SurrealDB compute node paired with dedicated storage — resizing means giving this node more CPU, memory, and I/O.Vertical scaling: a single SurrealDB compute node paired with dedicated storage — resizing means giving this node more CPU, memory, and I/O.

Horizontal scaling on the Scale plan adds compute nodes to a multi-node cluster backed by SurrealDS. The storage tier handles replication, consensus, and distributed transactions. Use Scale when you need to survive node failure, spread query load, or prefer to avoid operating a self-hosted distributed cluster.

Horizontal scaling: multiple SurrealDB compute nodes backed by SurrealDS distributed storage.Horizontal scaling: multiple SurrealDB compute nodes backed by SurrealDS distributed storage.

See Cloud architecture for how Start and Scale differ.

Signals to scale include CPU pegged near limits, memory pressure, disk growth trending toward limits, connection saturation, and latency SLOs breached under normal traffic. Schedule resizes during maintenance windows when possible; some changes may cause brief reconnects.

On Scale, also watch per-node balance and storage growth on the cluster — horizontal scale may require both more compute units and additional storage.

Change the instance type, compute units, or storage from the Cloud console or Surrealist, following any confirmation steps for your plan. After scaling, re-check metrics and query performance to validate the new size.

For operational scaling detail in the deployment guide, see Scaling operations.

Was this page helpful?