5 ms·

As an low-profile developer who's been using CouchDB for a long time, some weeks ago I've written some quick personal opinions on what CouchDB has become: http:

by fiatjaf 10y ago

As an low-profile developer who's been using CouchDB for a long time, some weeks ago I've written some quick personal opinions on what CouchDB has become: http://fiatjaf.on.flowi.es/about-couchdb/ http://fiatjaf.on.flowi.es/about-couchdb/

drhayes9 10y ago
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?
- brightball 10y ago
  PouchDB is my best guess
  - davidbanham 10y ago
    Agreed. PouchDB is the go to if you want an "embedded couch".
- fiatjaf 10y ago
  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.
pokstad 10y ago
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.
- willholley 10y ago
  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-improved-pricing-model/ https://developer.ibm.com/bluemix/2016/07/26/cloudant-public...
  - pokstad 10y ago
    Interesting, this came out in July and Cloudant still hasn't updated their pricing structure on their site.
- janl 10y ago
  CouchDB and PouchDB helped with the Ebola outbreak last year: https://www.youtube.com/watch?v=1sLjWlWvCsc https://www.youtube.com/watch?v=1sLjWlWvCsc Of course there is loads more, but this is the stuff that keeps us devs going.
  - k__ 10y ago
    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.
    - janl 10y ago
      CouchDB is the only one of those that a non-profit could deploy at scale without paying loads of money for licenses or support.
jchrisa 10y ago
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.
- fiatjaf 10y ago
  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.
willholley 10y ago
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/ https://blog.couchdb.org/2016/08/15/feature-replication/ [2] http://docs.couchdb.org/en/2.0.0/api/database/changes.html#selector http://docs.couchdb.org/en/2.0.0/api/database/changes.html#s...

by fiatjaf 10y ago

drhayes9 10y ago

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?

brightball 10y ago
PouchDB is my best guess
- davidbanham 10y ago
  Agreed. PouchDB is the go to if you want an "embedded couch".
fiatjaf 10y ago
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.

pokstad 10y ago

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.

willholley 10y ago
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-improved-pricing-model/ https://developer.ibm.com/bluemix/2016/07/26/cloudant-public...
- pokstad 10y ago
  Interesting, this came out in July and Cloudant still hasn't updated their pricing structure on their site.
janl 10y ago
CouchDB and PouchDB helped with the Ebola outbreak last year: https://www.youtube.com/watch?v=1sLjWlWvCsc https://www.youtube.com/watch?v=1sLjWlWvCsc Of course there is loads more, but this is the stuff that keeps us devs going.
- k__ 10y ago
  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.
  - janl 10y ago
    CouchDB is the only one of those that a non-profit could deploy at scale without paying loads of money for licenses or support.

jchrisa 10y ago

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.

fiatjaf 10y ago
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.

willholley 10y ago

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/ https://blog.couchdb.org/2016/08/15/feature-replication/ [2] http://docs.couchdb.org/en/2.0.0/api/database/changes.html#selector http://docs.couchdb.org/en/2.0.0/api/database/changes.html#s...