That's a helpful TPS Report.

TIL `SAVEPOINT` can occur in a BEGIN ... END SQLite transaction, and that works with optimizing batch size on a particular node with a given load.

Is there a solution for SQLite WAL corruption?

From https://news.ycombinator.com/item?id=45133444 :

> "PSA: SQLite WAL checksums fail silently and may lose data" https://news.ycombinator.com/item?id=44672902

> sqlite-parquet-vtable, [...]

▲

matharmin 5 hours ago | parent [-]

As mentioned in those threads, there is no SQLite WAL corruption if you have a working disk & file system. If you don't, then all bets are off - SQLite doesn't protect you against that, and most other databases won't either. And nested transactions (SAVEPOINT) won't have have any impact on this - all it does in this form is reduce the number of transactions you have.

	▲	westurner 5 hours ago \| parent [-]
		> working disk & file system And a working ECC or non-ECC RAM bus, and [...]. How bad is recovery from WAL checksum / journal corruption [in SQLite] [with batching at 100k TPS]? And should WAL checksums be used for distributed replication "bolted onto" SQLite? >> (How) Should merkle hashes be added to sqlite for consistency? How would merkle hashes in sqlite differ from WAL checksums? SQLite would probably still be faster over the network with proper Merkleization