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. Until you have restored a backup, you cannot be sure it works.
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, with each node in a different availability zone. One node, the sequencer, orders every write, and a node in another zone, the acker, keeps a second copy. A commit is acknowledged only after both have written it to disk. Architecture describes this write path. Availability is a property of that design rather than something added on top:
Node loss is survivable. When the node holding the sequencer or the acker role fails, another node takes the role over, and writes pause until it has. 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. Two nodes hold the sequencer and acker roles. The third is what lets the cluster lose a node and still keep two copies of every write.
The one node failure a cluster cannot cover is the loss of the sequencer and the acker at the same moment. Writes then wait until one of the two returns, however many nodes the cluster has, because only those two hold every acknowledged write. Placing them in separate zones makes this unlikely.
Scale still needs backups. Replication protects against infrastructure failure, not against a mistaken DELETE or a bad migration. Those reach every copy 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.