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.
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.