SQLite is almost certainly more battle tested by this point than even MySQL for things like this. Alongside having somewhere around the ballpark of 10¹² current

SQLite is almost certainly more battle tested by this point than even MySQL for things like this. Alongside having somewhere around the ballpark of 10¹² current deployments (yes, 1 trillion) it has about 600 lines of testing code per line of its actual source code. https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html To give you an idea of just how hardcore this is, they stress test something as fundamental as malloc() independently: >SQLite, like all SQL database engines, makes extensive use of malloc() [...] On servers and workstations, malloc() never fails in practice and so correct handling of out-of-memory (OOM) errors is not particularly important. But on embedded devices, OOM errors are frighteningly common and since SQLite is frequently used on embedded devices, it is important that SQLite be able to gracefully handle OOM errors. >OOM testing is accomplished by simulating OOM errors. SQLite allows an application to substitute an alternative malloc() implementation using the sqlite3_config(SQLITE_CONFIG_MALLOC,...) interface. The TCL and TH3 test harnesses are both capable of inserting a modified version of malloc() that can be rigged to fail after a certain number of allocations. These instrumented mallocs can be set to fail only once and then start working again, or to continue failing after the first failure. OOM tests are done in a loop. On the first iteration of the loop, the instrumented malloc is rigged to fail on the first allocation. Then some SQLite operation is carried out and checks are done to make sure SQLite handled the OOM error correctly. Then the time-to-failure counter on the instrumented malloc is increased by one and the test is repeated. The loop continues until the entire operation runs to completion without ever encountering a simulated OOM failure. Tests like this are run twice, once with the instrumented malloc set to fail only once, and again with the instrumented malloc set to fail continuously after the first failure. I don't say this as a hater of MySQL! SQLite is built with very different constraints in mind. But data consistency is something it really shines at.