Unclear MVCC vs single-writer support?

[marceline-cramer]

Hi, I'm not a database expert (yet).

I'm trying to judge whether I should use Fjall for my application over Redb. I'm having a hard time figuring out whether "single-writer transactions" in the context of Fjall means specifically that individual write transactions can only run at a time, or if #79 makes it so that I can have multiple write transactions running concurrently.

My main use case for my app is that it's barely above the KV store in terms of actual served logic, but I expect lots of clients to potentially being interacting with the app's server over RPC. I'm worried that "single-writer transactions" (as described in the README and rustdocs) might mean that each application has to wait for unlock for every other application's write before it's its turn to write, even if they're manipulating entirely disjoint data collections.

Redb in its docs says that it supports "MVCC support for concurrent readers & writer, without blocking," which certainly sounds like it meets my requirements, but #79 is tripping me up again because it explicitly states that it supports multiple concurrent write transactions. Fjall certainly seems to have a much simpler API than Redb, so I'm not super eager to choose Redb over it.

Certainly if I had a bit more database literacy I could figure this out myself, but I'm asking instead! I'd really appreciate any help clearing my confusion on this. Thank you for your time. :)

[marvin-j97]

I'm having a hard time figuring out whether "single-writer transactions" in the context of Fjall means specifically that individual write transactions can only run at a time, or if #79 makes it so that I can have multiple write transactions running concurrently.

Yes, a single-writer lock will actually serialize all write transactions (read transactions are not affected).
The advantage is that there is no additional logic such as conflict checking in transactions, so if your transactions are short, it is unlikely to be a bottleneck.

If your transactions are longer running (so the commit time is comparatively short), the SSI transactions can run the transaction body in parallel, but SSI transactions may fail because of conflicts and have to be rerun (optimistic concurrency control).
So if your conflict rate is high, SSI transactions may perform badly.
When the transaction is not conflicted, it is committed.
The commit stage is still serialized, as writes then go into the write-ahead log, which they need to exclusively lock.
If your workload is very multi-threaded and write-heavy, the only way to really increase the throughput of the commit stage is by implementing #96.

Redb in its docs says that it supports "MVCC support for concurrent readers & writer, without blocking," which certainly sounds like it meets my requirements

ReDB (like LMDB) only allows a single writer transaction, note that it says readers and writer (not writers).
So using single writer locks will get you behaviour more similar to ReDB, while SSI transactions are more like RocksDB's OptimisticDB.

[marceline-cramer]

Oh, I think this is actually exactly what I was looking for, then! Thank you very much for the help.