[GH-ISSUE #76] CouchDB 3 and the couch-per-use "plague" #469

New issue

Closed

opened 2026-04-12 22:01:37 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-04-12 22:01:37 -06:00

Owner

Originally created by @fredguth on GitHub (Apr 2, 2022).
Original GitHub issue: https://github.com/jo/couchdb-best-practices/issues/76

I have 2 questions:

Has any of these best practices changed with CouchDB 3?
What is your reaction on "Rule 5: Avoid the database-per-user anti-pattern like the plague" best practice from Cloudant?

Originally created by @fredguth on GitHub (Apr 2, 2022). Original GitHub issue: https://github.com/jo/couchdb-best-practices/issues/76 I have 2 questions: 1) Has any of these best practices changed with CouchDB 3? 2) What is your reaction on ["Rule 5: Avoid the database-per-user anti-pattern like the plague"](https://www.ibm.com/blogs/cloud-archive/2019/03/cloudant-best-and-worst-practices-part-1/) _best practice_ from Cloudant?

gitea-mirror closed this issue

2026-04-12 22:01:38 -06:00

gitea-mirror commented

2026-04-12 22:01:39 -06:00

Author

Owner

@jo commented on GitHub (Apr 3, 2022):

The best practices described here are also valid for CouchDB 3. However, I haven't worked with Linked Documents for a while, so this section may be outdated.

The DB-Per-User question is a bit complicated. It depends. The biggest bottleneg here is replication: the CouchDB replicator has its weaknesses when it comes to continuous intra-cluster replication. Here, the individual changes feeds are polled round-robin, which creates a high load. If validate doc update functions are also used, this load increases. Therefore, it may make sense to implement application-specific replication logic. That is, if the application knows when something changes, it can instruct single-shot replications, thus reducing the load.

I'm looking forward to the upcoming new features of CouchDB, especially the per-document access patterns, which would be a big step here.

@jo commented on GitHub (Apr 3, 2022): The best practices described here are also valid for CouchDB 3. However, I haven't worked with Linked Documents for a while, so this section may be outdated. The DB-Per-User question is a bit complicated. It depends. The biggest bottleneg here is replication: the CouchDB replicator has its weaknesses when it comes to continuous intra-cluster replication. Here, the individual changes feeds are polled round-robin, which creates a high load. If validate doc update functions are also used, this load increases. Therefore, it may make sense to implement application-specific replication logic. That is, if the application knows when something changes, it can instruct single-shot replications, thus reducing the load. I'm looking forward to the upcoming new features of CouchDB, especially the per-document access patterns, which would be a big step here.

gitea-mirror commented

2026-04-12 22:01:40 -06:00

Author

Owner

@fredguth commented on GitHub (Apr 4, 2022):

Thanks for the explanation!

@fredguth commented on GitHub (Apr 4, 2022): Thanks for the explanation!

No labels

pull-request

question

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/couchdb-best-practices#469

No description provided.

Rows
Columns