# Storage engines

What a storage engine does for SurrealDB, and how to think about choosing one.

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 models](/docs/manage/self-hosted/deployment-models.md) for how engines map to hosting models.

How to choose: start from your hosting model (embedded, single server, cluster) and read about [deployment models](/docs/manage/self-hosted/deployment-models.md) together with [architecture](/docs/architecture.md). Then follow the embedding guides for your language under [embedding SurrealDB](/docs/build/embedding.md) for what your SDK supports today - capabilities vary by platform and release.