LiteDB

Before checking this out, people might want to take a look through the issues and pull requests of which there are 500+ and 50+ respectively [1]. I was really optimistic about this project and it was headed in a great direction, but it's not in a production ready state, and it seems that the main guy behind it has decided to move onto other things. It's been about a year since there was any significant activity. I just mention this because a lot of these little issues might only become more apparent after integrating the db into your project and so it can be a bit annoying. [1] - https://github.com/mbdavid/LiteDB

Wow! You're not wrong: https://github.com/mbdavid/LiteDB/issues/1783 Surprising..

One reason: SQLite is slower than LiteDB in this benchmark project created by the LiteDB inventor https://github.com/mbdavid/LiteDB-Benchmark https://github.com/mbdavid/LiteDB/issues/291 Another (lesser) reason is the similarity to MongoDB methods, if that's what you are used to it will feel familiar, but no MongoDB server needed.

One of those I've tried is LiteDB - https://github.com/mbdavid/LiteDB. I liked it. It's small yet capable. If you are familiar with MongoDB, you will feel right at home. It's great for .NET developers as it's written in C# but since it's Netstandard 1.3 compatible, you can presumably run it under Ubuntu or Mac OS or wherever else the new .NET 5 runtime works. I've got a C# app running on ARM64 the other day - just saying. I wrote about my experience playing with LiteDB here - https://tomaskohl.com/code/2020-04-07/trying-out-litedb/. It's not an in-depth look at all, just a few notes from the field, so to speak.

Looking at the file format limitations [1], it doesn't seem like a good fit for an alternative to ODT files. (A cursory judgment based solely on this wiki page has me wondering if they are using the best data structure for an Index, but again, very cursory.) A question is why you would want to replace the current ODT format? "Just" a zipped up file tree of XML documents and image assets is a pretty robust format choice. There are unzip programs on almost every platform. XML isn't always everyone's favorite markup language, but it's well supported by almost every language ecosystem, and still roughly okay to humanly eyeball if needed. The relative inefficiencies of the textual encoding and verbosity of XML are directly suited for compression efficiency of a Zip file. For most trade-offs of a document file, it's a somewhat resilient option,