# Architecture

The single-node and multi-node topologies behind the Start and Scale plans, and what each one means for growth and recovery.

This page explains the two topologies an instance can run on, and what each one means for growth and recovery.

The plan you choose when you [create an instance](/docs/manage/instances/create.md) selects the topology.

Instances build on [the layered architecture of SurrealDB](/docs/architecture.md), which separates storage from compute. That separation lets an instance grow, replicate, and recover without you sharding or resharding the database yourself.

## Start: single node

The **Start** plan provides one compute node backed by a dedicated disk. Compute and storage are sized together and resized together, and the node holds the only copy of the working data.

<img src="~/assets/img/image/cloud/light/start-single-node-light.png" darkSrc="~/assets/img/image/cloud/start-single-node.png" alt="Diagram of the single-node topology: one SurrealDB compute node paired with its own dedicated disk-based storage volume." />

This topology suits development, staging, and production workloads that fit on one node and can tolerate a short recovery window. It scales vertically: as load grows, you move to a larger instance type. See [Scaling](/docs/manage/instances/scaling.md).

Because there is a single node, there is no failover inside the instance. [Backups](/docs/manage/instances/backups.md) are the recovery mechanism. See [High availability](/docs/manage/instances/high-availability.md) for what that means in practice.

## Scale: multi-node cluster

The **Scale** plan runs a cluster of three compute nodes or more over distributed storage. Each node runs in a different availability zone within the region, backed by its own disk.

<img src="~/assets/img/image/cloud/light/enterprise-multi-node-light.png" darkSrc="~/assets/img/image/cloud/enterprise-multi-node.png" alt="Diagram of the multi-node topology: three SurrealDB compute nodes, each in a separate availability zone with its own storage volume, coordinating through a shared distributed storage layer." />

Data is replicated continuously between nodes, and every node serves reads, writes, and queries. The storage layer handles replication, quorum consensus, and distributed transactions. A query therefore does not need to know which node holds which data.

The practical consequences are:

- **Node loss is survivable.** A quorum of the remaining nodes keeps serving. Three nodes is the minimum, because three nodes leave a majority when one node is out for a failure, an upgrade, or maintenance.
- **Query capacity scales horizontally.** Adding nodes adds throughput. Vertical scaling is bounded by the largest available instance type.
- **Self-hosting the same topology is more work.** Running it yourself means operating Kubernetes, storage replication, patching, backups, and upgrade orchestration. Scale covers that work for you. Compare [Self-hosted deployment models](/docs/manage/self-hosted/deployment-models.md).

> [!NOTE]
> Several Scale capabilities are still on the roadmap: object-storage backing, cross-region replication, automatic sharding, and read replicas. Object-storage backing keeps hot data on disk and cold data in object storage, which in turn enables instant database branching. See [Pricing](https://surrealdb.com/pricing) and [Roadmap](https://surrealdb.com/roadmap) for current availability.

## Related pages

- **[Scaling](/docs/manage/instances/scaling.md):** resizing nodes and adding them.
- **[High availability](/docs/manage/instances/high-availability.md):** what each topology survives.
- **[Self-hosted deployment models](/docs/manage/self-hosted/deployment-models.md):** running the same topologies on your own infrastructure.