Multi-node SurrealDB requires shared distributed storage — a backend that every query node can reach with transactional consistency. A single RocksDB file on one server (or one Kubernetes pod) is not a multi-node cluster; it is the single-node, on-disk model.
For managed production clusters, see the Scale plan on SurrealDB Cloud, which runs on SurrealDS. For self-hosted highly available setups on Kubernetes, see Amazon EKS, Google GKE, and Azure AKS.
The section below uses TiKV as a local open-source playground for experimenting with multi-node connectivity. It is not the storage engine behind Cloud Scale or Enterprise SurrealDS deployments.
Local development
The following starts a local distributed-storage playground for development, then connects SurrealDB to it.
Start SurrealDB against the playground endpoint:
The default logging level for the database server is info. To control the logging verbosity, specify the --log argument. The following command starts the database with debug level logging, resulting in more logs being output to the terminal. If extra verbosity is not needed, specify a lower level or simply remove the flag, which will default to the info level.
Configure your initial root-level user with --user and --pass. The root user is persisted in storage, so you do not need those flags on subsequent starts.
Change the listen port with --bind:
After running the above command, you should see the SurrealDB server start up successfully.
For details on the different commands available, visit the CLI tool documentation.
Environment variables
Environment variables such as SURREAL_TIKV_REQUEST_TIMEOUT can be set to modify distributed-storage client behaviour. See distributed storage environment variables.