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.
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. The engine you pick ties your operational playbook to concrete behaviours such as compaction, backup and 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 models for how engines map to hosting models.
To choose an engine, start from your hosting model (embedded, single server, cluster) and read about deployment models 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.