I worked on a local first version of an app I sell. I use CouchDB to store user data so it was pretty easy to implement because CouchDB will sync a local CouchDB to the Cloud based CouchDB as soon as any changes are made. That app is now 20 years old and over those years I've had users who quit using it call me years later to ask if I could give them access to their expired account or a copy of all their data. CouchD…
Thanks for sharing your experience, what was the app? Personally, I don't think I would have gone through the trouble as well. For example, I used to have a ton of Evernote entries and don't think I would setup a personal CouchDB just to get access to it. A middle ground could be a file path to an sqlite file that can be copied, opened or backed up in the cloud.
In the early versions of the app I used CGI.pm to store and get user data and that was very fast and efficient, and the format for storing data was similar to CouchDB's (JSON), so it felt more familiar for me to work with.
I had never worked with SQL before making that app. I had a partner back then create a new version that used an SQL db. I did this mostly because I felt like the app wasn't keeping up with web trends and he had been pestering me to use SQL in the next version for about a year.
What he ended up with was buggy to the point of users calling and screaming at me and after a year he still couldn't get it right. Back then news of SQL dbs getting hacked were common and after buying several books on SQL I realized that to be proficient required years of study and experience.
CouchDB had just come out around then so I looked into it and for me that's been much easier to work with, and do so securely. It's practically designed for an app like ezInvoice. PouchDB.js has made it easy for me to work with.
If you're already proficient with SQL there's probably no compelling advantage to using CouchDB/PouchDB, but it's a really good tool set for building web apps.