Tigris is an open source alternative to MongoDB Atlas. Tigris uses FoundationDB's transactional key-value interface as its underlying storage engine. This blog post will explore how Tigris offers serializable transactions using FoundationDB and compare it with MongoDB.
I am one of the Co-Founders of Tigris Data and we use FoundationDB extensively. I am doing a multi-part series on the architecture of Tigris (the open source developer data platform). In this blog post, I will walk you through our data layout on FoundationDB, key structure, and key compression, how we manage schemas, and how are schema changes propagated in a consistent way across distributed application workers.
Thank you for explaining your use case. This is one of the features we have in mind to support use cases similar to yours for storing videos, images, etc. But this may not happen this year. It would be great if you could add something here https://github.com/tigrisdata/tigris/issues that will help us track and monitor similar use cases.
You can use our typescript client for everything not only for Schemas. Here is a section that has examples on how to use it https://docs.tigrisdata.com/typescript/. Please let us know if anything is confusing.
Allowing default values for columns is definitely doable and we can also implement it in a similar way by filling it in during the query. But changing the type of a field to an incompatible type is tricky and needs more constraints and external machinery to fix the history.
Both keys and values in FoundationDB are simple byte strings and keys are treated as members of a total order, the lexicographic order over the underlying bytes, in which keys are sorted by each byte in order.
The IDB idea is very cool. We are doing something similar to manage our platform users, apps, etc(internal metadata for our platform). But extending it for the use case you mentioned seems very interesting!
There is no limit on array size or on nested data; the only limit is on the document size, which we will slowly relax. But if the object is deeply nested, then we need to extract all these nested keys(which may be slightly costly) and index them as we also allow filtering on any key of the object. If the depth is not significant then the cost is negligible.