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.