4 ms·

So what's the deal with the unpopularity of CouchDB? It's seems like a compelling database, but i've yet to run into it in the wild.

kache_ 5y ago
I've used it, its pretty decent given you understand the internals.
gedy 5y ago
It is/was nice, just an early NoSQL DB with a lot of interesting features. Just better options came about to take its mindshare. We used it about 11 years ago for an internal marketing CMS system and the replication and attachment support were a good fit.
- rat9988 5y ago
  What betters options would you have in mind? Asking from curiosity, I don't follow this space closely.
  - gedy 5y ago
    It's been a while, but seems like many people wanted something simpler like MongoDB for a NoSQL document database. CouchDBs map/reduce queries were hard to get people's heads around, many people didn't need attachments, etc.
- tehbeard 5y ago
  What's out there with a better client device sync option? This is something I've been looking for for a few PWAs that need to operate on bad/no network, and most other solutions are build your own entire sync setup, or magic-in-a-box you can't tune. With Couch/pouch, I can sync with a filter/several filters to make sure the subset of data I need is on the device.
  - gedy 5y ago
    Yeah agreed that's really cool. Closest I've seen is Apollo client, but to your point you have a lot less fine grained control.
- jFriedensreich 5y ago
  I would highly object to "better options came about". I am not debating maybe a better fit to your specific problems came along, but in general case of the sweet spot for couchdb there are no obvious better alternatives. The sweet spot being "a schemalesss json database with a rest api and first level support for master-master and online/offline replication that values your data safety and reliability first and everything else second."
  - gedy 5y ago
    Yes what I meant by "better options" was for the devs just looking for a schemaless/document NoSQL database. They weren't needing CouchDB's sweet spot basically. The project I mentioned was great fit though.
Already__Taken 5y ago
npm does or did run on it https://github.com/npm/npm-registry-couchapp https://github.com/npm/npm-registry-couchapp if that's what you mean by in-the-wild
tehbeard 5y ago
Beyond the meta of it being old/mature and thus not continually piercing the tech newsspace with releases etc. Querying in a more ad-hoc way (vs. building indexes ahead of time and querying by key, etc) is a bit janky / not 1st class (I think mango addresses this but not entirely sure). The runtime being erlang? It certainly seemed to be the cause of some issues when I tried to run it in WSL, or atleast my lack of knowledge with erlang made diagnosing it more trouble. The JS query server engine is/was fairly old (I think it might have jumped to a more recent version of Spidermonkey at some point), and hooked up in a way that, while more modular, limits the performance (documents have to be serialized to/from the engine in another process, rather than just natively passed in) The authorization model is... unique. You can limit down to a doc/field level who can submit changes via validate_doc_update(...) in a design doc. So allowing those with a reviewer role to only be able to edit a notes field on a document, while the user in the author field has full access to the other fields is possible. But read access is at the database level, as in you can either read the db, or not. The way around this for having "private" storage is enabling a feature to make a db per user automatically and assign them rights, but this is more complicated to manage client side (two dbs to talk to) and replication even more of a nightmare if stuff needs to be shareable instead of just private.
- janl 5y ago
  Good observations, let me add the current state to that: > Querying in a more ad-hoc way (vs. building indexes ahead of time and querying by key, etc) is a bit janky / not 1st class (I think mango addresses this but not entirely sure). Mango does address this. > The JS query server engine is/was fairly old On the one hand, running an old JS engine isn’t big trouble for CouchDB, especially with transpiration tools available, but we now support modern SpiderMonkey up to version 91. The main benefit for CouchDB users is modern JS syntax being available. > The authorization model is... unique. per-doc-auth is in the works, no ETA, and the first iteration is going to be limited, but it’ll address the main issues for db-per-user users.
jFriedensreich 5y ago
I would not call it "unpular" in the sense that it does have a strong base of community and most people, that once "got it" really loved it. I know people that tell me how they miss being able to work with it and keep using it privately even after switching jobs etc. Unpopular in the sense of "not popular"/too few people know about it or consider it currently is true. For one, couchdb does not have a major VC backed owner with a huge marketing budget, this is also good aspects, eg. as a true apache project no single company can just take over or do major changes against the community motivated by their investment structure. From a technical perspective the admin interface "fauxton" never really felt finished and debugging views is not welcoming for new users. Also creating good and working indexes is critical but is still too hard for novices even with mango syntax, especially as devs are now used to things like query autocompletion and friendly error messages/ warnings while typing or simple guis. The managed hosting story is also not compelling as forced ibm cloud was a big step back for many non corporate users after the cloudant acquisition and other players seem too small/niche to consider. Apart from traditional marketing, couchdb does not create a lot of news, as it is just REST, you don't need client apis or very integrated frontend libraries, the features scope is quite settled. I have email alerts for hot fixes and apart of that i check the progress once a year and apart from that things just work.

kache_ 5y ago

I've used it, its pretty decent given you understand the internals.

gedy 5y ago

It is/was nice, just an early NoSQL DB with a lot of interesting features. Just better options came about to take its mindshare. We used it about 11 years ago for an internal marketing CMS system and the replication and attachment support were a good fit.

rat9988 5y ago
What betters options would you have in mind? Asking from curiosity, I don't follow this space closely.
- gedy 5y ago
  It's been a while, but seems like many people wanted something simpler like MongoDB for a NoSQL document database. CouchDBs map/reduce queries were hard to get people's heads around, many people didn't need attachments, etc.
tehbeard 5y ago
What's out there with a better client device sync option? This is something I've been looking for for a few PWAs that need to operate on bad/no network, and most other solutions are build your own entire sync setup, or magic-in-a-box you can't tune. With Couch/pouch, I can sync with a filter/several filters to make sure the subset of data I need is on the device.
- gedy 5y ago
  Yeah agreed that's really cool. Closest I've seen is Apollo client, but to your point you have a lot less fine grained control.
jFriedensreich 5y ago
I would highly object to "better options came about". I am not debating maybe a better fit to your specific problems came along, but in general case of the sweet spot for couchdb there are no obvious better alternatives. The sweet spot being "a schemalesss json database with a rest api and first level support for master-master and online/offline replication that values your data safety and reliability first and everything else second."
- gedy 5y ago
  Yes what I meant by "better options" was for the devs just looking for a schemaless/document NoSQL database. They weren't needing CouchDB's sweet spot basically. The project I mentioned was great fit though.

Already__Taken 5y ago

npm does or did run on it https://github.com/npm/npm-registry-couchapp https://github.com/npm/npm-registry-couchapp if that's what you mean by in-the-wild

tehbeard 5y ago

Beyond the meta of it being old/mature and thus not continually piercing the tech newsspace with releases etc. Querying in a more ad-hoc way (vs. building indexes ahead of time and querying by key, etc) is a bit janky / not 1st class (I think mango addresses this but not entirely sure). The runtime being erlang? It certainly seemed to be the cause of some issues when I tried to run it in WSL, or atleast my lack of knowledge with erlang made diagnosing it more trouble. The JS query server engine is/was fairly old (I think it might have jumped to a more recent version of Spidermonkey at some point), and hooked up in a way that, while more modular, limits the performance (documents have to be serialized to/from the engine in another process, rather than just natively passed in) The authorization model is... unique. You can limit down to a doc/field level who can submit changes via validate_doc_update(...) in a design doc. So allowing those with a reviewer role to only be able to edit a notes field on a document, while the user in the author field has full access to the other fields is possible. But read access is at the database level, as in you can either read the db, or not. The way around this for having "private" storage is enabling a feature to make a db per user automatically and assign them rights, but this is more complicated to manage client side (two dbs to talk to) and replication even more of a nightmare if stuff needs to be shareable instead of just private.

janl 5y ago
Good observations, let me add the current state to that: > Querying in a more ad-hoc way (vs. building indexes ahead of time and querying by key, etc) is a bit janky / not 1st class (I think mango addresses this but not entirely sure). Mango does address this. > The JS query server engine is/was fairly old On the one hand, running an old JS engine isn’t big trouble for CouchDB, especially with transpiration tools available, but we now support modern SpiderMonkey up to version 91. The main benefit for CouchDB users is modern JS syntax being available. > The authorization model is... unique. per-doc-auth is in the works, no ETA, and the first iteration is going to be limited, but it’ll address the main issues for db-per-user users.

jFriedensreich 5y ago

I would not call it "unpular" in the sense that it does have a strong base of community and most people, that once "got it" really loved it. I know people that tell me how they miss being able to work with it and keep using it privately even after switching jobs etc. Unpopular in the sense of "not popular"/too few people know about it or consider it currently is true. For one, couchdb does not have a major VC backed owner with a huge marketing budget, this is also good aspects, eg. as a true apache project no single company can just take over or do major changes against the community motivated by their investment structure. From a technical perspective the admin interface "fauxton" never really felt finished and debugging views is not welcoming for new users. Also creating good and working indexes is critical but is still too hard for novices even with mango syntax, especially as devs are now used to things like query autocompletion and friendly error messages/ warnings while typing or simple guis. The managed hosting story is also not compelling as forced ibm cloud was a big step back for many non corporate users after the cloudant acquisition and other players seem too small/niche to consider. Apart from traditional marketing, couchdb does not create a lot of news, as it is just REST, you don't need client apis or very integrated frontend libraries, the features scope is quite settled. I have email alerts for hot fixes and apart of that i check the progress once a year and apart from that things just work.