Are there any production-ready open-source HA storage options for self-hosted SurrealDB?

[x-at-01]

Hi SurrealDB team and community,

We are evaluating SurrealDB for self-hosted deployments and looking into high-availability (HA) architectures.

According to the official documentation on Multi-node SurrealDB:

"The section below uses TiKV only as a local open-source playground for experimenting with multi-node connectivity. It is not the storage engine behind Cloud Scale or Enterprise deployments, and it is not recommended for production HA."

Given that TiKV is documented as not recommended for production HA:

1. Are there currently any production-ready, open-source storage engines supported for multi-node / HA self-hosted deployments?
2. If TiKV is only intended for local playground experiments, what is the recommended architecture for self-hosted users requiring high availability without proprietary Cloud Scale / Enterprise licenses?
3. Are there plans or roadmaps to support open-source distributed backends for production HA in the community/open-source edition?

Thanks for any insights and guidance!

[goutamadwant]

Based on the current deployment documentation, the direct answers are:

1. No supported production-ready open-source multi-node/HA backend is currently listed. TiKV is explicitly a Community playground, while RocksDB is a single-node on-disk model and SurrealKV is still beta.
2. The supported Community self-hosted production shape is a single active SurrealDB node with durable storage and tested backups/restores. Kubernetes can restart that node on a persistent volume, but that is recovery/failover automation—not active-active database HA, and multiple pods must not share one RocksDB file.
3. The public docs do not make a commitment for a Community distributed backend. Only the maintainers can give a roadmap answer.

So if multi-node HA is a hard requirement today, the documented SurrealDB paths are Cloud Scale or self-hosted Enterprise/SurrealDS. Otherwise, design the Community deployment around single-node failure recovery and state the resulting RTO/RPO explicitly; if neither is acceptable, choose a database with a supported open-source consensus/storage layer rather than treating the TiKV playground as production-ready.