I know that it is a common trope that Couch / Pouch seems to think that SQL databases don't work for offline replication and you need their "batteries-included" solution. However, it's not the only solution and every app in the app store that works offline has had to deal with it. Most of those are using SQL databases.

In truth, what Couch does is force you to handle conflict events which gives you a convenient platform level place to put some of your automatic conflict/merge code. A lot of merge code is UI however and Couch does not help with that at all.

Detecting conflicts is a subtle thing, but it's not necessarily a one-size-fits-all problem as couch would have us believe. I

It also gives you versioning for free (which is pretty easy to implement in SQL)

However, at the end of the day, every developer must make application level decisions on how to handle merge conflicts. Couch/Pouch does not obviate this - it just forces you to deal with it and lets you think about your application a little differently. Once you have to deal with merges and conflicts in your application code, it's more a matter of designing your application to have fewer conflicts (either through better merging, vector clocks, pessimistic locking, etc)

I wish I could have used it but all my other data is in a battle-tested Postgres db, being nicely backed up regularly on Heroku without fail. My CouchDB was on a Google Cloud server, using a brand new replication framework as backup.

I don't really mean to rag on Couch - I think it's a promising idea. But I ended up wasting several weeks going down this path only to throw it away because I didn't feel like it was production-ready.

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.

Any parts of the project open source and/or have you written any detailed blogs on the development process?

Would love to read more about the challenges you encountered and how you solved them.

Even moreso the move to Phoenix is enticing for a project of mine. Any tips there?