I think compromises at the application layer are the trick here. Instead of trying to make every possible aspect of the business system ACID compliant, perhaps only small aspects of it actually need this level of transactional isolation.
Alternatively, perhaps you have a business model which is amenable to document-based storage. If you can reduce your business modeling to:
Serializable GUID-keyed objects - Any arbitrary business type instance that can be turned into JSON bytes.
GUID-keyed transactions - Document the specific object GUID(s) to be locked for a transaction.
You can very easily entertain a resilient, clustered solution. Going wide on GUID keys is trivial compared to alternative approaches. If you need to support any degree of SQL grammar or row-based storage, you are in for a completely different dimension of pain. I would never subject myself to this. Instead, I would reach for SQLite or Postgres.
Alternatively, perhaps you have a business model which is amenable to document-based storage. If you can reduce your business modeling to:
Serializable GUID-keyed objects - Any arbitrary business type instance that can be turned into JSON bytes.
GUID-keyed transactions - Document the specific object GUID(s) to be locked for a transaction.
You can very easily entertain a resilient, clustered solution. Going wide on GUID keys is trivial compared to alternative approaches. If you need to support any degree of SQL grammar or row-based storage, you are in for a completely different dimension of pain. I would never subject myself to this. Instead, I would reach for SQLite or Postgres.