Hi! JD here, Hydra's CTO. NoSQL is certainly a challenge but we have a few ideas/angles on how to solve it. Certainly we plan to start with simple queries and then iterate from there based on what our customers need.
We are really excited about the prospect of bringing SQL and NoSQL together!
This is definitely something I could see myself paying for --- but only if I could somehow get relational performance for nasty Mongo aggregate queries.
Aggregations by their nature are designed to work on a substantial footprint of data. As a result changing the query model is unlikely to speed up the operation of aggregation. In fact, as most of these libraries require the data to be shipped to the client (whereas aggregation queries run on the server) you will likely see substantially reduced performance.
Hydra doesn't ship data to the client in order to then do further work like aggregations -- that's the whole point of Hydra -- but that also means that you won't be able to "workaround" a performance issue with an underlying data store. For that, we'd need to find a way to replicate the data to a data store that can solve the aggregation performance issue.