Production multi-node SurrealDB uses shared distributed storage with replication and consensus — not TiKV. For managed HA, use the Scale plan. Self-hosted multi-node clusters on Kubernetes are available with SurrealDB Enterprise.
For a single-node RocksDB deployment on Kubernetes — including a cluster you create with EKS, GKE, or AKS — start with Deploy on Kubernetes. For a local open-source distributed-storage playground only, see Run a multi-node cluster.
The managed control planes
Each of the three major clouds offers a managed Kubernetes control plane. The control plane is the only part they manage for you; how SurrealDB storage is provided is still your choice — single-node RocksDB on a persistent volume, or a multi-node cluster on distributed storage (Scale or Enterprise).
| Provider | Service |
|---|---|
| AWS | Amazon Elastic Kubernetes Service (EKS) |
| Google Cloud | Google Kubernetes Engine (GKE), including Autopilot |
| Microsoft Azure | Azure Kubernetes Service (AKS) |
Choose a path
| Goal | Path |
|---|---|
| Managed multi-node HA (recommended for most teams) | A managed Scale cluster — no TiKV or TiDB operator to run |
| Self-hosted multi-node HA on EKS, GKE, or AKS | SurrealDB Enterprise with distributed storage (operator and runbooks shipped with Enterprise) |
| Single SurrealDB pod, RocksDB on a volume | Deploy on Kubernetes on a cluster you manage |
Local experiment with Community tikv:// | Run a multi-node cluster (not Scale or Enterprise storage) |
Why not TiKV for production HA
Older guides walked through the TiDB operator and a TiKV cluster as the shared store behind SurrealDB on managed Kubernetes. That path is not the storage engine behind Scale or Enterprise deployments. Prefer a Scale or Enterprise cluster for production HA; keep TiKV for local Community experimentation only.
Next steps
Deployment models — single-node vs multi-node vs managed
Instances — the managed option
Scale — pricing for managed multi-node clusters
Observability once an instance is running