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. For self-hosted highly available setups on Kubernetes, see Amazon EKS, Google GKE, and Azure AKS.
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.