Surprised to see this on HN, but I am one of the maintainers of this (I expect Nolan will end up finding this too) so happy to answer any questions about it.
From how I understand it, a local database will persist until the browser clears its cache. What happens in the situation where the cache clearing takes place while you are using the pouchdb database? Can that condition be handled?
I thought pouch might be a good fit for a web app you could use offline - you'd need connectivity to login or whatever, and sync the database initially. Then you'd modify the local one and sync it when it's all done, saving round trips to the server.
But that also raises the question - on the server side, is one database per user feasible? IIRC Couch can only handle 100 or so different databases on one instance. And you can't do views across them.
There are actually several layers of "cache" inside of a browser, including the traditional HTTP cache (which is global) as well as the site storage, which includes stuff like IndexedDB, WebSQL, LocalStorage, AppCache, and window.caches (all of which is per origin).
This site storage _can_ be cleared by the browser (it's "temporary" per the spec), but in practice it isn't very frequently cleared unless the machine is running low on space. E.g. Chrome only does it if a site exceeds 20% of total per-origin browser storage (https://developer.chrome.com/apps/offline_storage) whereas Edge is extremely conservative with clearing IDB because it's considered user data (e.g. email drafts in Outlook). In any case, when the browser does clear this storage, it clears everything at once for that origin, so the user essentially has the experience of visiting the site for the first time. This is why it's a good practice to periodically sync your PouchDB data to CouchDB because it can be lost in rare cases.
Also there is a new Storage spec that allows site authors to designate certain buckets of per-origin storage to be persistent, but this typically requires a user permission and isn't widely supported yet: https://storage.spec.whatwg.org/
This sounds _nuts_ from a traditional database mindset, but works great in Couch.
You can then create another database that replicates from all the user databases in order to perform your aggregate queries on the back end.
Sounds weird coming from my Postgres and MySQL background, but works great in practice, depending on your use case and if you clear out old revisions and unused docs, which for our use case can number into the thousands fairly rapidly.
That sounds horribly space inefficent.
Everything in software is a trade-off. This trades space efficiency for multi master replication with first class offline app experiences.
For many cases, that's a fine trade. Disks are cheap. If that isn't a fine trade for a particularly large dataset, use a different technology that's better at space efficiency and worse at other stuff.
You could also encrypt data.
For pluggable storage engines our node.js adapter uses leveldown, so any *down backend can be plugged in. https://pouchdb.com/adapters.html has some more information about this.
For p2p yup its been something quite a few people have been using pouchdb for, one of the more notable examples has been http://thaliproject.org/, the core storage format is entirely compatible with p2p (inherited from couchdb)
PouchDB is a CouchDB implementation in the browser. I don't think your sync with other db would be easy and I believe there is no such desire in the project roadmap.
https://pouchdb.com/faq.html#sync_non_couchdb
Basically, your other data base probably handles conflicts in a different way to Couch that would make syncing this way nonsensical.
If you're happy to handle that yourself, the Couch replication protocol is well documented and there are plenty of libraries written for it.