Can I ask why? From my other comment on this article I don't see the use case for an embedded NoSQL, but I'd like to.
Where and how would you use it? What, if anything, do you currently use in its place? If nothing, is there something you could use instead? Why is it better than a serializing your own domain model (assuming you have a domain model), or other alternatives?
Probably a better description would be an embeddable document store is what I'm looking for.
I want to store my objects in the database without having to flatten out its nested structure. I also want to be able to search those nested structures. I want the database engine to handle creating the fields if they don't exist. I don't want to deal with schemas. Each document in a collection should not care if the fields are different from each other.
These are all the things I'm used too using in MongoDB, I don't want to go back to SQL type databases. I thought I saw a SQLite driver that mimicked a MongoDB like system but I can't seem to find it.
Is there anything about the way you query your data that a traditional serialized object store wouldn't handle? Being that you want it embedded and therefore local, I'd imagine you're talking about relatively small amounts of data and your performance concerns aren't too extreme?
That would be perfect except you need a commercial license if your going to bundle it with a commercial product. Really wish they would just put the pricing on the site.
I'm starting to think you're right. Maybe a traditional serialized object store is the way to go.
Where and how would you use it? What, if anything, do you currently use in its place? If nothing, is there something you could use instead? Why is it better than a serializing your own domain model (assuming you have a domain model), or other alternatives?