In-memory | Running

For the purposes of getting started with SurrealDB quickly, we will start an in-memory database which does not persist data on shutdown.

surreal start mem

As SurrealDB runs with in-memory storage by default, the following command is identical to the above.

surreal start

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.

surreal start --log debug memory

The SurrealDB server runs with authentication by default. In order to disable it, the --unauthenticated flag can be passed in.

surreal start --unauthenticated memory

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.

surreal start --user root --pass 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.

surreal start --user root --pass secret --bind 0.0.0.0:8080

After running the above command, you should see the SurrealDB server start up successfully.

surreal start --user root --pass secret --bind 0.0.0.0:8080

Output

2026-03-05T03:15:21.128111Z  INFO surrealdb::core::kvs::ds: Starting kvs store in memory
2026-03-05T03:15:21.129330Z  INFO surrealdb::core::kvs::ds: Started kvs store in memory
2026-03-05T03:15:21.130104Z  INFO surreal::dbs: Operation succeeded operation="check_version" attempts=1
2026-03-05T03:15:21.130137Z  INFO surrealdb::core::kvs::ds: This is a new SurrealDB instance. Initialising default namespace 'main' and database 'main'
2026-03-05T03:15:21.131439Z  INFO surreal::dbs: Operation succeeded operation="initialise_defaults" attempts=1
2026-03-05T03:15:21.131465Z  INFO surreal::dbs: Initialising credentials user=root
2026-03-05T03:15:21.131495Z  INFO surrealdb::core::kvs::ds: Credentials were provided, and no root users were found. The root user 'root' will be created

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 and 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.

surreal start --user root --pass secret "mem://tmp/data?versioned=true&snapshot=60s"

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

Run your first query

With the server running, open a second terminal and connect to it with the surreal sql command. This starts a SurrealQL REPL against the server, using the credentials from the step above.

surreal sql --endpoint http://localhost:8000 --username root --password secret --namespace main --database main --pretty

Create a record. There is no need to define the table first, because SurrealDB creates it on the first write.

CREATE person:tobie SET name = "Tobie", city = "London";

Output

[
	{
		city: 'London',
		id: person:tobie,
		name: 'Tobie'
	}
]

Select it back to confirm the round trip.

SELECT name, city FROM person;

Output

[
	{
		city: 'London',
		name: 'Tobie'
	}
]

When you finish, exit the REPL with Ctrl+C. Data in an in-memory server is lost on shutdown unless you enable the persistence options above.

Next steps

Query from your application with an SDK - each language guide starts with a connect-and-query walkthrough.
Try SurrealQL without a server in the Studio Sandbox.
Learn the query language, starting with the SELECT statement.