Sounds good. Using Fuel to serialize/deserialize should be fine, but I had unhappy experience with early versions where a newer Fuel version could not read content written by earlier Fuel versions.
In my mind, a disk-based B-tree is the fundamental data structure for any database (e.g. GemStone, Omnibase, Relational DBs all have it), but I don���t see it mentioned so far. Everything else about a "database" is optional, IMHO.
For example, a query language is not needed at all, if the data items are equivalent to objects running in a Smalltalk VM - the query language is Smalltalk itself. It ���just��� has to mesh well with the indexing.
Another feature is MVCC. How much concurrency is needed, and how it is implemented, is an implementation choice. I���d mentioned LMDB on Discord. It has single writer, many readers. Choosing to have multiple simultaneous writers has a cost. When there is one or more big machines, it seems sensible have the big machines use multiple writers. But when these databases scale up, the database ends up sharded, with parts of the data spread over multiple machines. Why not just start there, with many small machines owning a small part of the database, and use just a single writer process. The application can then deal with concurrency, conflicts and assembling results, in whatever manner best suits.
So I see the end goal to be a set of frameworks, and some ���recipes��� for putting the frameworks together, to solve the ���persistence��� problem. These are just half-baked ideas of course. I���ll follow the project, and hope to contribute.