SurrealDB sits on top of a storage engine—the component that persists keys and values on disk (or in memory) inside transactions. The query engine speaks SurrealQL; the storage engine decides how durability, concurrency, and replication behave underneath.
Why it matters: different engines optimise for different deployment shapes. A single embedded process cares about latency and simplicity; a distributed cluster cares about fault tolerance and horizontal capacity. Picking an engine is not a one-off aesthetic choice—it ties your operational playbook to concrete behaviours (compaction, backup, recovery).
Typical options you will see in SurrealDB deployments include RocksDB for mature local disk storage in write-heavy server workloads, SurrealMX (memory) for in-process or server in-memory workloads, and SurrealKV (beta) for embedded and local-first workloads where lower resident memory and simpler in-process behaviour are priorities. In-memory modes are ideal for tests and scratch work, and can also be used in embedded deployments when you enable Redis-like SurrealMX persistence. See Deployment for how engines map to hosting models.
How to choose: start from your hosting model (embedded, single server, cluster) and read about deployment together with architecture. Then follow the embedding guides for your language under embedding SurrealDB for what your SDK supports today – capabilities vary by platform and release.