A database earns trust by showing how it fails, not by saying it doesn't. We break an ArcadeDB cluster on purpose, check every recorded operation with formal checkers, and publish the suite so you can do the same.
Jepsen runs a database cluster under real network partitions, process crashes, pauses and clock skew, then checks the recorded history with formal checkers: Knossos for linearizability and Elle for transaction isolation. Our suite is open source at github.com/ArcadeData/arcadedb-jepsen (Apache 2.0), runs on a 5-node cluster in Docker, and uses a fresh cluster for every test.
This is not an official Jepsen analysis. Jepsen LLC did not commission, run, review or certify these tests. We wrote them in-house with the open-source Jepsen framework and publish everything so the methodology can be scrutinized. The 34 baseline tests run in ArcadeDB's default development mode, which does not flush the write-ahead log to disk at commit: they prove replication and consensus are correct, not that a commit survives a power cut. The 10 LazyFS tests switch on production mode, which does flush at commit, and then simulate power loss to prove it.
| Workload | What it checks | Checker |
|---|---|---|
| bank | ACID balance conservation across concurrent transfers | Custom conservation invariant |
| set | No acknowledged write is lost during replication | Custom set checker |
| elle | Transaction isolation: G0, G1a, G1b, G2, lost updates | Elle |
| register | Linearizability of single-key read, write and CAS on the leader | Knossos |
| register-follower | Linearizability when reads go to a follower (ReadIndex path) | Knossos |
| register-bookmark | Read-your-writes on followers via commit-index bookmarks | Knossos |
| ha-convergence | After faults heal, every node is live and holds every acknowledged write | Custom convergence checker |
Network partitions (iptables), SIGKILL crashes, SIGSTOP/SIGCONT pauses,
clock shifts of up to 60 seconds, combinations of all of them, and simulated power loss on
LazyFS, which drops unsynced writes and then kills the JVM.
G1c is excluded from the Elle checker because reads in the harness run as separate HTTP calls after commit; the blog post explains why.
Long-duration runs (minutes, not hours), disk corruption and Byzantine faults, geo-replication latency, and one compound worst case for follower reads. The full write-up lists each gap.
The cluster under test is the same Raft high availability stack you run in a client-server deployment. How replication, quorums and read consistency work is explained on the reliability and HA page.
The Jepsen suite is public. Run it, read the results, and open an issue if you find something we missed.
Yes, with an in-house test suite built on the open-source Jepsen framework, published at github.com/ArcadeData/arcadedb-jepsen. The April 2026 blog post reported 34 of 34 tests passing on the Raft HA stack. The repository README now reports 44 of 44: the same 20 leader and 14 follower tests plus 10 LazyFS power-loss tests. This is not an official analysis by Jepsen LLC, which did not commission, run, review or certify these tests.
No. Jepsen LLC did not commission, run, review or certify these tests. Arcade Data wrote them in-house with the open-source Jepsen framework and publishes the suite, the methodology and the results so anyone can rerun and scrutinize them.
Yes, 10 of the 44 tests do. They run the server in production mode on LazyFS, a filesystem that drops unsynced writes, and then kill the JVM. The 34 baseline tests run in the default development mode, which does not flush the write-ahead log to disk at commit, so they verify replication and consensus rather than on-disk durability.