I haven’t used it personally, but I looked at it enough to know that its goals are different from most DBs.

Isn’t it supposed to be mainly REST based and have a goal of being able to sync multiple nodes with expected connection loss in between?

I’ve never needed that on a project but it seems like it would work for some use cases. I hear good things about PouchDB.

I don't quite get pouchdb. Do you need to store multiple revisions of the same document in a browser database? Locks/transactions seem like a better approach here for writing to data client side.

The main point is to sync server side data to a client side database, smoothly, so that the application can continue to function offline and then resync once the connection is re-established.

Couch has always been good at this use case where systems on both ends may have changed in the disconnect time.

Realm looks like a much more modern solution to that problem.

Not familiar with Realm

but you could store Ids and revisions on any key/value store on the client. Why does the client need pouchdbs multiple revisions?

Not entirely sure what you misunderstand, PouchDB stores multiple revisions because thats how CouchDB's sync protocol works, the point of PouchDB was to match CouchDB semantics. PouchDB (as CouchDB) provides options to control how much you track (revs_limit, auto_compaction) and there are improvements we could do to handle tracking less information better

We use transactions under the hood actually writing data to indexeddb

I mean I both get it, and don't get it. CouchDB is all about master-master, and pouchdb just brings that to the browser. But at the same time I don't understand why you'd want a 'master' at the edge of the network, or the overhead of multiple revisions when a users browser isn't going to have tones of concurrent connections.

I fully admit I'm not very well-versed on databases or distributed computing, happy to have things clarified.

I had to make that distinction fairly early on wether PouchDB would be an edge client or a full node and I decided full node, tradeoffs either way but pros of being a full node:

1. Additional (p2p) use cases, honestly I dont use CouchDB much these days, I use express-pouchdb-server so I can embed pouchdb into my server easier than any other database, there is also pouchdb-server and p2p projects like Thali (http://thaliproject.org/)

2. CouchDB existed, sync is super hard, writing an edge client would have meant designing it myself, writing a couchdb clone meant I needed to make a lot less decisions about how it worked while being very confident it would work, The test suite runs the same tests against pouchdb/couchdb to ensure compatibility (and replication via each configuration)

I don't follow your reasoning here: why would the badness of an application propagate up to the technology it's based on? Even the best systems in the world can be abused.

I can understand it working the other way around, e.g. an application initially seems good, but opinion of it drops when finding out it's written in COBOL.

I can understand if the CouchDB authors agreed with criticism of their application, and explained them as being inherent to the language. AFAIK they haven't. EDIT: Ah, looks like the author wrote CouchDB!

I can understand if Erlang and its proponents held CouchDB up as a shining example of their philosophy. AFAIK they don't (e.g. it doesn't appear on https://www.erlang.org/community ).