Document transaction isolation level(s)

[fritzblue]

I do not see transaction isolation levels mentioned anywhere in the documentation. They're mentioned in the whitepaper, but it's unclear (to me) what the final isolation guarantees are expected to be.

It would be great to document this in an easy-to-find place.

[fritzblue]

It has been nearly a year since asking this question. ACID compliance and isolation levels/guarantees are a fundamental question to answer when considering a new database. Will any attention be given to this question?

[mumoshu]

@fritzblue Hey! Sorry for being so late. In short, it depends on the KVS (i.e. "storage engine") you use for SurrealDB. For example, it's Snapshot Isolation when you use TiKV or RocksDB as the storage engine and Strict Serializable for FoundationDB.

I'm not sure where to start but let me try- sorry if I repeat anything you already know.

SureralDB has a pluggable KVS architecture. Similar to MySQL's storage engine is pluggable, SurrealDB's storage engine, the KVS, is pluggable.

We don't have our own distributed transactions on top of the underlying KVS (TiKV, FDB, RocksDB, etc) (yet), which means the guarantee is the one provided by the KVS you choose.

Does this answer your question @fritzblue?

[gedw99]

Could you show the api and semantics on the docs ?

also give examples of where the distributed transactions cause issues when network partitioning occurs. Too many systems are all rosey when everything is perfect but should be honest about the consequences when a router starts flapping or a network partitions and reconciles.

Don’t mean to be negative . Just want honest.

call me maybe Jespen should be run on the systems nightly like other distributed db systems are doing so that the test suite is public and regressions become obvious from a PR.