The chattiness is mostly addressed with _bulk_get in CouchDB 2.0 - Pouch will automatically use it if the server supports it. Another option is to stick a HTTP/2 proxy in front of your CouchDB instance - the chatter to the db is ultimately still there but it significantly reduces the latency cost to the PouchDB client. There are plans to add first class HTTP/2 support to Couch but for remote client architectures just adding a proxy should be a significant improvement. Projects like https://github.com/cloudant-labs/envoy take this a step further and provide an extensible proxy (e.g. you can do sub-database access control, etc).
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.
> 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.
possibly this has changed recently but I don't think medical records software is subject to the same standards as medical device software (in Europe, at least).
It's important to remember that EMRs are there to support healthcare professionals who are used to working with incomplete / incorrect information all the time. For example, a patient isn't going to have a drug dispensed to them without a pharmacist checking it (and, frequently, asking the prescribing doctor to clarify/amend questionable doses or instructions).
> possibly this has changed recently but I don't think medical records software is subject to the same standards as medical device software (in Europe, at least).
That is indeed the case (medical record software not being classified as a medical device software product in Europe). However medical record software has been added to also be covered some ISO 80xxx standard. However in the USA medical record software is considered a class B or even class C medical product by the FDA, depending on if the software is used just for record keeping or actively used for therapy planning.
So
a) Class A, B, C in this context means safety class(=IEC62304?)
b) I was under the impression that EHR is not FDA regulated in US? (There was been lots of discussion about this though)
I'd have to look into my most recent seminar materials (we did only tangent on medical record software since this was focused on diagnostics and treatment devices) but as far as I recall, there was a slide that EHR software falls under FDA regulation; in contrast to EU law. Let me have a look at it tomorrow, when I'm in the office, where I placed the seminar stuff.
For MongoDB lovers, PouchDB supports MongoDB-style querying via https://github.com/nolanlawson/pouchdb-find. MongoDB doesn't have the fundamental sync primitives that CouchDB has so I wouldn't expect a similar solution which supports MongoDB on the server.
That's fine for scaling reads - writes, not so much. The leader election in MongoDB has been problematic in the past (https://aphyr.com/posts/284-call-me-maybe-mongodb) but I think they have made recent moves to address this.
ES isn't really meant to be used as an operational datastore (although I appreciate some do use it that way). CouchDB provides strong durability and master-master replication. It's also very easy to sync changes from CouchDB (https://github.com/elasticsearch/elasticsearch-river-couchdb) to ES so they make a good complimentary pair. Use CouchDB for the raw data (where you want strong durability and write scalability) and use ES to search over it.
Although it's been a quiet few years, the project is on the up again. 2014 was a big year for CouchDB - CouchDB 2.0 developer preview was released (more on this in a sec) [1], IBM acquired Cloudant (and has made it available as on-premise offering), Cloudant Query (MongoDB-style querying for CouchDB)[2] was contributed to CouchDB. PouchDB, Couchbase Mobile and Cloudant Sync (all replication-compatible with CouchDB) all saw major new releases and increased uptake. Much more detail on all of this is on the CouchDB blog [3].
CouchDB 2.0 adds dynamo-style clustering support (similar to Riak and Cassandra) in addition to the replication(sync) protocol used by the CouchDB ecosystem [4]. It also includes all the fixes / performance improvements based on Cloudant's operational experience over the last 5 years.
That said, document databases are certainly a niche. CouchDB is a good choice if you need strong durability (writes are always fsync'd - to multiple copies when clustering) and consistent performance as your database scales (querying options may seem restrictive but are designed to scale very well). As others have pointed out, the RESTful interface to CouchDB makes it a good fit for web and mobile applications which can query the database directly without an app tier. PouchDB [5] and various mobile datastores which implement the sync protocol [6][7] allow you to also take your database to a browser or mobile client and work with it when disconnected which is pretty compelling.
database-per-user is a common pattern with CouchDB. If you need to aggregate data across your users for reporting etc then you can use a server-side replication to create a "master" database which is only accessible to your internal users.
You could also use filtered replication but it is:
a) not scalable
b) not secure (the whole db would still be accessible to all users)
Couchbase has a different spin on this via "channels" though I'm not sure how it interoperates with PouchDB.
Couchbase Sync Gateway's channels are just slices through the data. The mechanism is internal to the Sync Gateway (you write a JS function that says who can see which channels and which channels a doc belongs to.) Replicating clients don't Need to know about this filtering, so channels work great with all flavors of Couch.
