Thanks for the recommendation, I'm a little bit skeptical of MongoDB, but realm looks nice, Firebase I'm a little reluctant on being so dependant on google, but otherwise looks good.
PouchDB works well as the primary client store and can sync to CouchDB in the cloud. IMHO this is one of the more mature combinations that gives you a ready client side document database that takes care of data replication for you.
It's just unfortunate that running CouchDB in the cloud seems increasingly perilous. Since IBM acquired Cloudant, it's much tougher to run CouchDB "at scale PaaS" on any data center other than IBM's (for obvious reasons), whereas early Cloudant had robust Azure and AWS support for years.
I wish Couchbase were more helpful practically than they try to present themselves theoretically. Even if their products weren't so expensive the impedance mismatch between their version of CouchDB's sync APIs and their own APIs seems to increase by the year, and is pretty noticeable in how different it works from a PouchDB standpoint and how easy it is to break sync. (Impedance mismatches in allowable database names and _id keys are huge on their own that have massive repercussions in application design.)
Even CouchDB is not CouchDB anymore with impedance mismatches of its own between versions. On the one hand it's good that Cloudant upstreamed a lot of their cluster management tools directly into Apache CouchDB 2+ (even as they made their PaaS offering IBM Cloud only [or whatever it's name of the month is]), but huge architectural changes below the covers in CouchDB 3+ start to present their own sync issues akin to but distinct from Couchbase's (and even some of Cloudant's as they seem [?] to be diverging again into their own 2+ fork after all that work upstreaming stuff?).
More than ever, Azure CosmosDB's focus on bare minimum MongoDB capability and not supporting anything like CouchDB sync, despite having close the same raw ingredients (Cosmos' change feed looks a lot more like Couch's, but is just missing a couple subtle things to make it directly and immediately useful for Couch replication) seems like a "CouchDB is dead and not worth supporting" signal from Microsoft.
Unfortunately, I think PouchDB <=> CouchDB replication has past the "mature" point to the "decrepit" and "falling apart" stage, maybe to the point of "evolutionary dead end" if I'm feeling strongly pessimistic enough, and I've been for years trying to figure what to replace it with.
CouchDB 4 may change a few things in this space. It will be based on top of FoundationDB, which should make it a lot better for running "at scale PaaS".
Though from what I'm reading the FoundationDB internals are adding even more compatibility breaks from databases that work just fine in CouchDB 2 and PouchDB.
It's nice to see "we're trying for internals that make it easier to run it at scale", but it's not really a "at scale PaaS" play if there aren't any vendors on the major clouds that aren't IBM's interested in actually running whatever those internals are as a service.
That's a timely response and I too have to noticed that CouchDB may not have the best/compatible future. I have an existing product that depends on PouchDB in the client and the replication.
I'm not really into the managed db service offerings, I like to have control over it that they rarely offer.
My tentative solution for the application is to go with PouchDB on node.js on the backend too.
I like managed DB offerings because most of my projects rarely have the budgets for dedicated Ops people.
I'm worried that our infosec folks are about to kibosh IBM Cloud as a dependency on our projects (and when my projects started Cloudant had good Azure support still, sigh) and I'll have to scramble to figure out PouchDB replication endpoints again.
I did consider trying to bootstrap "Pouchserver" in an Electron deployed version of some of my apps. It's mostly just too bad that you can't count on Peer-to-Peer discovery to work at all in corporate environments.
At this point I have a half-baked notion of trying to build some sort of custom storage replication in CosmosDB. Like I said it's tantalizingly close to matching the CouchDB replication protocol and I keep hoping if I stare at documentation long enough something will click that there will be a really easy "hack" of a solution.
I was glancing at the documentation of RxDB's "GraphQL Replication" in case it gave me ideas. It's a huge departure from CouchDB replication, but maybe it is time to assume that CouchDB replication is not going to be easy moving forward anyway. (At least not without an Ops budget for it.)
