It's seems like a compelling database, but i've yet to run into it in the wild.
It's seems like a compelling database, but i've yet to run into it in the wild.
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.
> 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.
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.
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.