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, SurrealKV where you want SurrealDB’s own LSM-backed path (including features that evolve with the product), and TiKV for distributed setups that need coordinated readers and writers across nodes. In-memory modes are ideal for tests and scratch work, not durability.
How to choose: start from your hosting model (embedded, single server, cluster) and read the architecture overview for storage layers. Then follow the embedding guides for your language under embedding SurrealDB for what your SDK supports today—capabilities vary by platform and release.