Monastery Automates Hermitage Tests to Compare MySQL, MariaDB, and PostgreSQL Isolation Levels
Run Monastery on your database instances to validate isolation levels and adjust settings.
Run Monastery on your database instances to validate isolation levels and adjust configuration accordingly.
Summary
Monastery is a new open‑source tool that automates the Hermitage suite of concurrent‑transaction tests across MySQL, MariaDB, and PostgreSQL. It was built to run the same SQL scripts that Hermitage used manually, but now it can execute them against any database engine and report the anomalies that appear at each isolation level. The author ran Monastery against PostgreSQL 18.1, MySQL 9.7, and MariaDB after its 2024 switch to snapshot isolation, reproducing the expected PostgreSQL behaviour for all levels except Read Uncommitted, which PostgreSQL does not expose.
The results show that MySQL still fails to prevent the P4 lost‑update anomaly at Repeatable Read, and it also shows dirty‑write failures at Read Committed and Serializable. MariaDB, on the other hand, handles every anomaly that academic research says Repeatable Read should block, thanks to its snapshot‑based implementation. The tool also demonstrates that MySQL’s Serializable isolation can still allow dirty writes, a behaviour that MariaDB no longer exhibits. These findings confirm that MariaDB’s divergence from MySQL after 2024 has made its isolation semantics closer to PostgreSQL’s.
Monastery therefore provides a repeatable, automated way to benchmark isolation behaviour in production databases, making it easier for developers and DBAs to verify that their configuration matches the guarantees they need. The author encourages teams to run Monastery on their own instances to catch anomalies before they surface in application code.
Key changes
- Monastery automates Hermitage concurrent‑transaction tests across MySQL, MariaDB, and PostgreSQL
- It reproduces PostgreSQL 18.1 behaviour for all isolation levels except Read Uncommitted
- MySQL 9.7 still fails to prevent the P4 lost‑update anomaly at Repeatable Read and shows dirty‑write failures at Read Committed and Serializable
- MariaDB, after its 2024 snapshot‑isolation switch, blocks every anomaly that Repeatable Read should prevent, matching academic expectations
- MariaDB also handles an additional anomaly at Read Committed that PostgreSQL does not, illustrating its stricter guarantees
- MySQL’s Serializable isolation can still allow dirty writes, a behaviour MariaDB no longer exhibits
- The tool highlights the divergence between MySQL and MariaDB isolation semantics due to the 2024 changes
- Monastery provides a repeatable, automated benchmark for isolation behaviour, enabling teams to validate configurations before application deployment