Run a single-node, in-memory server
For the purposes of getting started with SurrealDB quickly, we will start an in-memory database which does not persist data on shutdown. This database is great for development and testing.
As SurrealDB runs with in-memory storage by default, the following command is identical to the above.
The default logging level for the database server is info, resulting in any informational logs to be output to the standard output. 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.
The SurrealDB server runs with authentication by default. In order to disable it, the --unauthenticated flag can be passed in.
However, for anything but simple testing, it is better to configure your initial root-level user by setting the --user and --pass command-line arguments. The following command starts the database with a top-level user named root with a password set to secret.
In order to change the default port that SurrealDB uses for web connections and from database clients you can use the --bind argument. The following command starts the database on port 8080.
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.
About SurrealMX
Since SurrealDB 3.0, in-memory storage runs on a backend called SurrealMX that also allows for versioned queries as well as persistent storage as a snapshot or AOL (append-only log).
SurrealMX uses an innovative commit pipeline designed around a key insight: by splitting the commit process into discrete, narrowly-scoped stages, multiple transactions can progress through different stages of the pipeline concurrently, much like instruction pipelining in a CPU.
Opting in to versioning and/or persistent storage is done by adding a path to the area to store the data as well as parameters to customise the type of storage and its behaviour. For example, the following command will start an in-memory server with versioning enabled that stores its data in in snapshots taken every 60 seconds.
Persistent storage is similar to that used in a product like Redis in that it is a convenience to allow in-memory data to persist, but not a true primary solution for long-term storage. For example, all the data stored must also be able to fit in RAM, and each snapshot is essentially a backup of the entire database. In addition, the persisted data is not compacted as is the case with RocksDB and SurrealKV. For more details on these parameters, see this page for the start command.
The following chart sums up the durability guarantees for SurrealMX in contrast with the effect on performance.
| Configuration | Survives Process Crash | Survives System Crash | Performance |
|---|---|---|---|
| No persistence | ❌ | ❌ | Fastest |
| Snapshot-only | ⚠️ (last snapshot) | ⚠️ (last snapshot) | Fastest |
| Async AOL + No fsync | ⚠️ (mostly) | ⚠️ (mostly + OS buffers) | Very fast |
| Async AOL + Interval fsync | ⚠️ (mostly) | ⚠️ (mostly + since last fsync) | Very fast |
| Async AOL + Every fsync | ⚠️ (mostly) | ⚠️ (mostly) | Very fast |
| Sync AOL + No fsync | ✅ | ⚠️ (OS buffers) | Fast |
| Sync AOL + Interval fsync | ✅ | ⚠️ (since last fsync) | Fast |
| Sync AOL + Every fsync | ✅ | ✅ | Slow |