In production, I have a horribly designed schema running couchdb 1.6 and node. It is serving a few thousand users, but has serious architectural issues. I star

In production, I have a horribly designed schema running couchdb 1.6 and node. It is serving a few thousand users, but has serious architectural issues. I started in freelance php web development, then switched to Ruby/Rails in 2006 and haven't looked back. I'm now thinking mobile access, unreliable networks, and global connectivity so it was time to re-survey the land. My MVP was with Node.js and CouchDB 1.6, but now I'm almost ready with a much more robust and well defined rewrite in Phoenix 1.3 and CouchDB 2.1 I agree that the 2.0 release was subpar. I actually needed to beta test against master because of a bug in the 2.0.0 release. But even with the rough patches, cutting Node.js and going all in on BEAM/OTP - I'm hoping will pay off for the next decade and then some. As far as CouchDB, I agree nothing is a magic bullet, but after better learning the entire CouchDB API surface, I was much better off at schema design and where to put logic in _design files vs application layer. I actually run a conflict-free schema now, and still benefit from master-master sync and first class offline support. I'm not saying the concepts are trivial, but when done in the correct CouchDB way, and getting all the benefits that come with that, I cannot imagine what it would take to manually handle sync logic with Ruby and SQL, which is why I asked.