Is there any way to avoid data loss in RocksDB, without setting SURREAL_SYNC_DATA environment variable?

[qarmin]

Recently, due to a power outage, we noticed that our RocksDB database became corrupted.
While investigating a possible solution, we came across the following:

surrealdb/crates/core/src/kvs/rocksdb/mod.rs

Line 65 in d5134c7

pub(crate) async fn new(path: &str) -> Result<Datastore> {

This code sets a number of parameters, including SYNC_DATA, which is configured here:

surrealdb/crates/core/src/kvs/rocksdb/cnf.rs

Line 6 in d5134c7

pub(super) static SYNC_DATA: LazyLock<bool> = lazy_env_parse!("SURREAL_SYNC_DATA", bool, false);

via the environment variable SURREAL_SYNC_DATA.

However, configuring this setting via an environment variable feels somewhat awkward and potentially unsafe in a multithreaded context.
Is there a way to set this parameter directly from Rust code instead?

Alternatively, is there another recommended option or setting that helps protect against data loss in the event of a sudden power failure?

EDIT: 2025-08
The corrupted database issue occurred in an application running on Windows Server, and we were unable to reproduce it on Linux.

Unfortunately, setting this flag had no effect, and on Windows Server, database corruption persisted during power outages. Because of this (and a few other issues), we ultimately migrated to PostgreSQL (embedded version).

[harrytran998]

Critical issue, but the team seems to focus on raising a new round of VC right now - Hope all the best, and can comeback to this one

[nickchomey]

the team seems to focus on raising a new round of VC right now

What makes you say that?

[nickchomey]

In-depth article about this here: https://blog.cf8.gg/surrealdbs-ch/

It also talks about how the benchmarks turns on the equivalent setting for some competing DBs, skewing the results/conclusions

[nickchomey]

I asked about this in today's AMA and tobie seemed to already be aware of this and the blog post, and directly addressed it all. I never had any sense that this was something deliberately sneaky - more of an oversight/perhaps mistaken choice.

He said they'll likely make SURREAL_SYNC_DATA default soon - maybe in v3.