# High availability

What a Start instance and a Scale cluster each survive, and how to plan for the failures they do not.

This page explains what each instance topology survives, and how to plan for the failures it does not.

High availability means the database stays reachable and consistent when a component fails or during planned maintenance. How much of that you get depends on the topology, which the plan sets when you [create the instance](/docs/manage/instances/create.md).

## Start: single node

A **Start** instance runs on one compute node with a dedicated disk. That is simple and inexpensive, and it means there is no failover inside the instance. If the node, the disk, or the host underneath fails, connections drop until the instance recovers.

What you get instead is managed recovery. Patching, snapshots, and host replacement are handled for you, and [backups](/docs/manage/instances/backups.md) are the mechanism for recovering from data loss or a corrupted state.

Plan around that:

- **Treat backups and a rehearsed restore as the recovery path**, not in-instance redundancy. A backup you have never restored is an assumption, not a plan.
- **Give clients retry and reconnect logic.** Resizes, version upgrades, and host recovery all produce a short window where connections fail.
- **Accept a recovery window** in the service level you promise upstream, or move to Scale.

## Scale: multi-node cluster

A **Scale** cluster runs at least three SurrealDB nodes over distributed storage, with each node in a different availability zone. Availability is a property of the architecture rather than something added on top:

- **Node loss is survivable.** The storage layer coordinates replication and quorum consensus, so the cluster keeps serving while a node is unavailable. Three separate single-node instances would not do this, because they would be three independent databases.
- **Maintenance is not an outage.** Version upgrades roll through nodes one at a time. Query capacity dips while each node restarts, but the cluster stays reachable. See [Versions and upgrades](/docs/manage/instances/versions-and-upgrades.md).
- **Three nodes are the minimum for a reason.** Three nodes leave a majority when one is out for a failure, an upgrade, or maintenance. Two nodes would not.

Scale still needs backups. Quorum protects against infrastructure failure, not against a mistaken `DELETE` or a bad migration. Those replicate to every node exactly as intended.

## Comparing the two

| Requirement | Start | Scale |
| --- | --- | --- |
| Tolerate a recovery window during host failure | Yes | Yes |
| Survive the loss of a node without manual failover | No | Yes |
| Stay reachable through a version upgrade | No. Expect a reconnect | Yes, through a rolling upgrade |
| Scale query throughput horizontally | No. Vertical resize only | Yes, by adding nodes |
| Recover from an application-level mistake | Restore a backup | Restore a backup |

## Beyond a single region

Both topologies run within one region. Node-level redundancy does not cover an outage that affects a whole region.

If your recovery objectives extend that far, plan for it at the application layer and rehearse a restore into a second region. A [backup restores into the region it came from](/docs/manage/instances/backups.md), so cross-region recovery uses a [logical export](/docs/manage/instances/import-and-export.md). Cross-region replication is on the roadmap. See [Architecture](/docs/manage/instances/architecture.md).

## Related pages

- **[Architecture](/docs/manage/instances/architecture.md):** the topology behind each plan.
- **[Scaling](/docs/manage/instances/scaling.md):** moving between sizes and node counts.
- **[Backups and recovery](/docs/manage/instances/backups.md):** snapshots, retention, and restore.