Can you still open the DB at all? Would you be able to copy the DB to another directory with dtlv?

The default setting of datalevin is not the most durable one. We write async by default. To avoid such situations, open DB with option like this {:kv-opts {:flags []}} , it will be fully durable and crash resistant, but suffer in write speed. There’s no free lunch.

It is debatable whether the default should be the most safe setting, which is LMDB’s default. Maybe it should. What do you guys think? If you guys agree, we can do that in the next major release.

dltv copy fails with the same error. I do wonder if it’s just about fixing/removing the corrupt page (I have zero understanding of the internals of LMDB). Anyway, I’ve just decided to rebuild the data from scratch (as it’s mostly ingesting a ton of data from a third party). In terms of defaults. I’m in two minds. Right now I’m mainly doing data analysis stuff with a bunch of initial transforms/normalisation transactions (inserts/updates) with a lot of data, crash resistant is important as there’s a lot of data so backups are big/slow and corruption can waste a bunch of time. If I was doing something more real time with a bunch of inserts daily backups and low downside to losing the last X hours of data, i’d probably take the hit on crash resilience for insert speed. I’m not sure there’s a correct default. As you said there’s no free lunch. If I recall correctly sqlite defaults to correctness/crash resilience and then when you want to get the performance you turn off the various safeties. I do feel opting in to the risk/performance tradeoff is probably a better default. Particularly if corruption means losing all your data not just what happened around the crash.

Sounds reasonable. 0.9.0 will have sync write default