surreal db has subcommands for running the server, executing SurrealQL, importing and exporting data, and maintenance tasks. Each page documents that subcommand’s arguments, related environment variables, and typical usage.
surreal db [OPTIONS] <COMMAND>| Subcommand | Purpose |
|---|---|
surreal db start | Run a SurrealDB server (in memory, on disk, or clustered). |
surreal db sql | Open an interactive SurrealQL shell or run queries from scripts. |
surreal db export | Dump a database to SurrealQL. |
surreal db fix | Apply data or schema fixes offline. |
surreal db help | Show help for surreal db or a subcommand. |
surreal db import | Load SurrealQL from a file into a database. |
surreal db is-ready | Health check for readiness probes. |
surreal db mcp Available since: v3.1.0 | Start the Model Context Protocol server on stdio for IDE integrations. |
surreal db ml | Work with machine-learning features from the CLI. |
surreal db module | Build and manage WASM modules (including Surrealism). |
surreal upgrade db | Upgrade the database component. Run by the launcher, not by surreal db. |
surreal db validate | Validate SurrealQL or configuration. |
surreal db version | Print the database client version, or the version of a server. |
Sidebar order: start and sql first, then remaining subcommands alphabetically.
Shared options
Every surreal db subcommand accepts -h / --help, which prints its arguments and options and exits, and the logging option group (-l / --log, --log-format, --log-file-*, and the socket and OpenTelemetry overrides). Each page lists --log alongside the command's own flags and shows the full group in its command help output.
Most flags have an equivalent environment variable, listed in the tables on each page and in full on the environment variables page.
What is not here
These subcommands act on a database that already exists or that you start yourself. Provisioning, pausing, scaling, and deleting SurrealDB Cloud instances is handled by surreal cloud instance, which calls out to surreal db for SQL, imports, and exports, so the pages here still describe what happens once a Cloud instance has been resolved.
Installing, upgrading and selecting versions of the database is done by the launcher, with surreal install db, surreal upgrade db, surreal use db@<VERSION> and surreal version, described in the launcher reference. The surreal db upgrade form is refused, with a message that names surreal upgrade db.
For installation and a minimal end-to-end example, see the surreal db overview.