I realize I'm just battering you with questions, so sorry about that. But here's another. Aside from the jdbc database being located on (percieved) more reliable/shareable hardware, is there any percieved advantage to using that over rocksDB for the tx-log? Are you trying to leverage commodity services/replication/availability, or is there something else going on?

In a single-server situation, I'm not seeing any downside to rocks/rocks for tx/doc. am I missing something in my analysis?

I get the central shared tx-log multiple indexing client thing, but if that isn't in play...

The metrics on this is that we trust the one (aggressively backed up) machine to be an acceptable single point of failure in my application. I have no problem leaning on RocksDB for this job, although I'd almost prefer having a single DB for both in this case - having a chance to use RocksDB machinery to keep the backup lively and not worry about consistency problems.

Probably not the use case you had in mind, but compelling in my case.

@hoppy no need to apologise 🙂 crux-jdbc is really only interesting as a crux-kafka alternative. Your preference for RocksDB is very sensible. That said, I am just about to test crux-jdbc with sqlite 😉

@mitchelkuijpers just announced https://github.com/avisi-apps/crux-xodus (MIT License) via the juxt-oss Zulip. This means we now have a pure Java backend (for both KV and TxLog) as an alternative to RocksDB and LMDB - great work! 💪

I have also added some instructions: https://github.com/avisi-apps/crux-xodus