As far as I can tell derby has zero story for datastores outside their json racer implementation. There's too much focus on realtime sync in all these frameworks. Even a realtime app like twitter needs complicated relational data. I want a framework that could build github. Derby does get major points for solving the seo and page load issue though.
In the future we would like to make it easier to do relational queries, but we plan to continue to use document stores instead of RDBMS's. Document stores are more easy to map to the way that data is represented in JavaScript, and they make it easier to reason about versioned data. Currently we support MongoDB, and we intend to support other similar stores like Redis, Riak, Postgres HSTORE, etc.
We just added a lot of functionality to our query system, but it is very much a work in progress. Making it easier to create queries that represent relationships is definitely on our task list.
I strongly disagree with this view of document stores as 'easier' to work with.
For some tasks, this is undeniably true, but for most business problems I think this is just not the case. The profound irony behind this is that schema-less document stores wind-up being so much less flexible due to them being inherently very denormalized.
The good case for document stores is:
1. You have data that really is a blob independent of having relations
2. You need high-performance or map-reduce (Riak, Dynamo, etc.)
Those two use cases are really rare in the real world. For most people there's a huge amount of code that leans on RDBMS strengths such as:
1. Integrity constraints
2. Very flexible ad-hoc queries.
3. Decades worth of work on tooling to mitigate rough edges, and solve tough problems that have come up before.
To clarify, I agree that RDBMS's are fantastic, and you pointed out many of the benefits. We are not religious about SQL vs NoSQL.
For our particular use cases, we think that document stores are a better fit, but I am not arguing that document stores are universally easier or better.
