Well, when I started with Meteor (January 2013), it was very easy to get a realtime app running (multiplayer HTML game) and the whole architecture was stable an

Well, when I started with Meteor (January 2013), it was very easy to get a realtime app running (multiplayer HTML game) and the whole architecture was stable and reliable. But it was difficult to extend the app beyond the specific features provided by Meteor and its own custom packages, which seemed like a potential dead-end. Derby, on the other hand, was very buggy from the start and it took a while to get anything working. But once the app was running, it was easy to add anything supported by Node.js/NPM/Express to it. In my case, I added some server-side Express routes (REST APIs) and server-side background processing (game logic). At that time, these seemed difficult to do in Meteor. During the past few months, Derby has proven occasionally unreliable and the documentation is sketchy (the query section, especially regarding security, is quite incomplete). But it has not been a dead-end. There's always some way to work around the problems, e.g. by using a "real" MongoDB connection to read some data on the server side when Derby's queries fail for some reason.