Early CouchDB contributor here. I agree with much of your write up, but I think the picture for apps built around replication is brighter than it seems. PouchDB has crazy momentum. Couchbase Mobile is getting baked into the next generation of infrastructure at places like GE and big airlines.

If you want filtered replication, we designed Couchbase Sync Gateway because we thought db-per-user was to heavy. What's fun is to think about the options for mix-and-match across the stack.

That's what keeps me liking the thing. My point was just that it could be have been so much better (not that I know HOW that would be, but it was the general idea of everyone involved in the past, it seems).

It would be cool to read more about where "replication apps" are being used and how.

I really like your write-up.

I'm sad that the Couchapp thing never took off or is getting de-emphasized. That was one of the really brain-bendy ideas about Couch that I loved, that these DB-side applications could also replicate to other people.

I'm only just catching up with Couch and finding the db-per-user stuff. Do you know of anyone shipping a Couch instance inside thick clients, like a traditional desktop application?

I guess CouchDB is not the easiest thing to install in a non-technical person computer, but PouchDB, on the other hand, is as easy as it can get.

I don't understand how projects like remotestorage, for example, aren't using Pouch and Couch and instead try to develop their own replication protocol without success for many years.

PouchDB is my best guess

Agreed. PouchDB is the go to if you want an "embedded couch".

My thoughts exactly. I'm not sure who CouchDB is supposed to be for anymore. The original developers who fell in love with it are moving on. Who is the audience for 2.0? Who does IBM hope to reach with Cloudant?

BTW, you are spot on about continuous replication. Try using continuous replication on Cloudant and you will end up with a fat bill.

There are a lot of use cases, particularly around multi-region/DC master-master replication, where CouchDB/Cloudant is a great fit. IBM also offers MongoDB, RethinkDB, Postgres as managed services and the MVCC/conflict model in Couch is still a standout feature. The other use case I see a lot of is offline-capable apps backed by Couch replication-compatible datastores (PouchDB, Cloudant Sync, Couchbase Lite).

Cloudant recently changed its pricing structure [1] (via IBM Bluemix) which should significantly reduce the cost of continuous replication - that may be worth a look if the current model is problematic.

[1] https://developer.ibm.com/bluemix/2016/07/26/cloudant-public...

Interesting, this came out in July and Cloudant still hasn't updated their pricing structure on their site.

CouchDB and PouchDB helped with the Ebola outbreak last year: https://www.youtube.com/watch?v=1sLjWlWvCsc

Of course there is loads more, but this is the stuff that keeps us devs going.

But isn't this more of a PouchDB benefit? The whole offline-apps in the browser thing, I mean.

Yes, the server probably runs CouchDB, but it could also be Cloudant or CouchBase etc. None of what is mentioned there is a USP of CouchDB itself.

CouchDB is the only one of those that a non-profit could deploy at scale without paying loads of money for licenses or support.

There's PouchDB Server also.

That wasn't production ready at the time and I'd argue it still isn't.

One thing that keeps me on CouchDB is Cloudant's pricing. It just destroys most of the competition. For example, the only RethinkDB hosting I know of is Compose and their pricing is $22/gb. Cloudant is $1/gb.

https://www.compose.com/pricing#rethinkdb-pricing

Some environments push you toward using it, in the case of IBM for example. Their Bluemix offering is very powerful and fast, they have Cloudant running all over that thing. It becomes the best and fastest way to store files.

That doesn't mean it's the best technology but it got me using it. It has been an enjoyable enough experience, not a lot of complaints. A better querying interface and the addition of an update operation would go a long way but those both seem to be included with this release.

I might even prefer it.

I think there's a lot for you to like in 2.0.

> The replication protocol, which supports multi-master, has changed little

Basically true, though with many interoperating, independent datastores it's a tricky thing to evolve. 2.0 adds an additional endpoint, _bulk_get which can significantly reduce the number of requests when CouchDB is paired with an on-device database such as PouchDB, Cloudant Sync or Couchbase Lite (the endpoint was inspired by the same feature in Couchbase). The CouchDB replicator itself has had many performance and stability improvements [1] and continues to be a significant focus for active development.

Also, CouchDB 2.0 introduces internal cluster replication using distributed Erlang. If you currently use CouchDB replication to bi-directionally replicate between machines on the same network for HA, replacing those with a CouchDB 2.0 cluster should be a big win.

> In other words: everybody seem to be looking at CouchDB as just a very poor and limited MongoDB.

Query doesn't pretend to be MongoDB-compatible - it provides a syntax that should be familiar to MongoDB users and more query flexibility than views allow. I think Query still has a fair way to go - this is the first release - but it's a move in the right direction.

As to whether CouchDB is viewed as "a very poor and limited MongoDB", they are very different databases. CouchDB is a good choice if you want a rock-solid JSON datastore which comfortably scales up to multiple TBs / many machines, with multi-master replication over unreliable networks. Query support, as you say, is not as rich as some other databases, so if that's more important to you, there are probably better options.

> Filtered replication was implemented, but it is slow to the point that no one recommends that you use them.

The new _selector filter [[2] in CouchDB 2.0 offers a significant performance improvement for filtered _changes. It should be a small change for replicators such as PouchDB can take advantage of this.

> About Couchapps, the special database features that powered them in the first place were left aside

I don't speak for the project, but it seems there has been much debate about this in the CouchDB community and the conclusion was that there are better solutions to most Couchapp-shaped problems than running application logic in the database. The features that combine to enable Couchapps haven't gone away and will benefit from the general improvements in 2.0, but they haven't been explicitly developed.

[1] https://blog.couchdb.org/2016/08/15/feature-replication/ [2] http://docs.couchdb.org/en/2.0.0/api/database/changes.html#s...