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.
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 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.
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, so cross-region recovery uses a logical export. Cross-region replication is on the roadmap. See Architecture.
Related pages
Architecture: the topology behind each plan.
Scaling: moving between sizes and node counts.
Backups and recovery: snapshots, retention, and restore.