Soooo stoked. This should make futzing with it to get started a lot easier.<p>I've been thinking about going to the FoundationDB summit to hopefully learn more... Does anyone have any good resources for learning about it? I've tried a few times but find the documentation a bit hard to grok. Maybe I'm just slow.<p>Also if you haven't seen it, this is one of the most amazing talks on distributed systems (because it's about testing them) I've ever seen (by Will Wilson from FoundationDB pre-Apple merger): <a href="https://www.youtube.com/watch?v=4fFDFbi3toc" rel="nofollow">https://www.youtube.com/watch?v=4fFDFbi3toc</a><p>Truly mind blowing how good FoundationDB is supposed to be for its use cases, and this Mongo layer is just the business when it comes to helping adoption.
> Document Layer has a familiar API, and is compatible with the MongoDB® protocol<p>Was wondering how I would replace MongoDB due to the shift in Licensing become more and more agressive.<p>Well , I think I found it.<p>Farewell MongoDB.
I'm a little confused. Does the "layers" concept mean the data which is stored in the core can be accessed in any valid manner that the layers allow? Or stated differently: if I've got a dumpster fire of data in a MongoDB that should have been in an RDBMS but moving to SQL would be too risky/slow would this allow me to schlep my Mongo data to FoundationDB and have the app continue to use the Mongo access methods while I start switching APIs over to querying by SQL in batches instead of One Big Volatile Move?
Is there any reason to expect fundamental inefficiencies with this approach vs a vertically integrated approach like a conventional document store? Any other downsides? I ask because this seems like to obviously good an idea to be true, so I need to look for the flip side before I get to excited. Otherwise, this laying seems like the obvious approach, and I can only lament that it's taken this long.
I don't know much about foundationDB, but when they say API compatible, are they referring to the technical TCP/IP connection stack, or ALSO the concepts of collections and the query language of MongoDB (such as aggregations, find, limit, etc..)<p>In other words can I throw a giant aggregation query with all mongo's various crazy query language syntax and it will.. work the same?
Sounds kind of "old" tech to have different layers for supporting different data models. Like the native multi-model approach of ArangoDB much better.<p>Their aggregation framework is pretty neat and the database also has full graph capabilities. Heck, I can even combine joins and graph traversal in the same query.
i think we are going to generally see more and more object to key-value mapping layers as the latter are widely available via cloud providers, and one basically needs something in the spirit of persistent-volume-claims from kubernetes land in the database layer that can be fulfilled by some key-value backend...
FoundationDB always sounded amazing, BUT, the way they disappeared when it was bought by Apple left a bitter taste in my mouth and I don't think I would ever trust them enough to build my business around their product.
Just wandering how will foindationDb compare to mongo in terms of the non functional s - performance, scale of a collection, number of collections, queries with and without indexes, aggregated, etc.