The [CouchDB concept](http://docs.couchdb.org/en/2.1.1/intro/why.html#a-better-fit-for-common-applications) speaks about self-contained documents. In other words: ALL related data is stored in a single concept, instead of splitting them in multiple tables and reference each other using FKs. > An invoice contains all the pertinent information about a single transaction the seller, the buyer, the date, and a list of the items or services sold. But this means that we end with redundant data in our database. Let's consider the invoice example: I buy 10 products over a period of time, which results in 10 invoices. Now several information are redundant, e.g. my billing address, delivery address and so on. That's at least a waste of space. Considering other use-cases, updating data can be very complex. If we have a blogging-cms like WordPress, every post-document contains metadata like author name/email and so on. If those information changes, we've to update a lot of documents. And we have to know the structure from all of them. E.g. the email could be used in posts, comments, log entrys and so on. When you think that the CouchDB allow a different form for any document, updating such information looks like a horrible tasks. I used MySQL as relational database for years and it seems much more meaningful to normalize such information, put e.g. users in a user table/collection, so that we can refer to some kind of PK. ### What is the purpose behind those concept in CouchDB? So my question is: Did I understood the concept of CouchDB properly, that they drop normalisation completely? I see the (theoretically?) benefit of having a better performance when no joins are required. Is the concept that we get a database with high throughput, but have to live with a (possible massive) amount of redundant data and we have to deal with a complex update-process when related metadata changes?

I am beginning to set up CouchDB on an Ubuntu 14.04 Server (yes, it expires next year) and I'm having troubles setting up SSL connections. For the moment, I don't have any CA signed certs for it, so I've been following the steps on the CouchDB docs . To list my changes to the config file: I have essentially kept them as the default except I set the bind address to 0.0.0.0 to be accessible over the network, and I moved my database_dir and view_index_dir to another path. For the SSL part, I followed the documentation precisely step-by-step, and restarted the couch service. From localhost, I get the response I expect: user@ubuntu:/etc/couchdb# curl -k https://127.0.0.1:6984/ {"couchdb":"Welcome","uuid":"43cf4aa1c38ef1feb9ec71ab93dddea3","version":"1.6.1","vendor":{"name":"Ubuntu","version":"14.04"}} Now, when I try to access the server over the network (which right now is just me accessing a VM from the host, having tried a bridged and host-only adapter in VBox): courtney@host:~$ curl -k https://192.168.10.38:6984/ curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.10.38:6984 At this point, I'm not sure what I'm missing. Is the documentation inaccurate? Or perhaps some packages I'm missing? I installed couch from the PPAs

I'm experiencing some issues with Apache CouchDB's database compression (version 3.3.3). Sometimes the process gets stuck midway, which causes significant difficulties. I'd like to know if it's possible to adjust certain settings—such as specifying which databases should be compressed, or setting the level of compression to be applied. I just asked ChatGPT, and it told me that CouchDB uses Snappy compression starting from version 3.x, and that this compression method isn’t configurable. So I decided to ask here in case someone has another idea or workaround. Thanks!

I'm relatively new to CouchDB (more specifically Cloudant if it matters) and I'm having a hard time wrapping my head around something. Assume the following (simplified) document examples: { "docType": "school", "_id": "school1", "state": "CA" } { "docType": "teacher", "_id": "teacher1", "age": "40", "school": "school1" } I want to find all the teachers aged 40 in California. Maybe my mind is still stuck on SQL world, but I'm having a hard time understanding how to run a query that uses data from different documents... PS. let me know if this is more suited to StackOverflow...

I'm new to CouchDB. I'm going through its config. Current configuration is as below. n = 3 q = 8 I understand n = 3 means 3 nodes and q = 8 means 8 shards. I don't have a cluster in place. Is it possible to make n = 1 without affecting data consistency? (This is a production DB.) Will it help me reduce overall DB size?

I would like to disable auto compaction on my CouchDB instance - so that I can get a full history of all the database updates. Is this possible? If so, how do I go about it? Is there a reason why I should not do this?

After building CouchDB from github. I run weatherreport as recommended in documentation to get the following error. How do you diagnose exactly whats going wrong? 17:38:27 WARN: 'escriptize' command does not apply to directory /home/test/workspace/CouchDB-ant_rhel/couchdb 17:38:27 [ * ] Setup environment ... ok 17:38:27 [ * ] Ensure CouchDB is built ... ok 17:38:27 [ * ] Ensure Erlang boot script exists ... ok 17:38:27 [ * ] Prepare configuration files ... ok 17:38:27 [ * ] Start node node1 ... ok 17:38:28 [ * ] Check node at http://127.0.0.1:15984/ ... ok 17:38:28 [ * ] Running cluster setup ... ok 17:38:30 [ * ] Exec command bin/weatherreport --etc dev/lib/node1/etc --level error ... ['['node1_diag35200@127.0.0.1'] [crit] Bad rpc call executing check weatherreport_check_memory_use: {'EXIT',{badarg,[{erlang,list_to_float,[],[{error_info,#{module => erl_erts_errors}}]},{weatherreport_util,binary_to_float,1,[{file,[115,114,99,47,119,101,97,116,104,101,114,114,101,112,111,114,116,95,117,116,105,108,46,101,114,108]},{line,80}]},{weatherreport_check_memory_use,check,1,[{file,[115,114,99,47,119,101,97,116,104,101,114,114,101,112,111,114,116,95,99,104,101,99,107,95,109,101,109,111,114,121,95,117,115,101,46,101,114,108]},{line,56}]},{weatherreport_check,check,2,[{file,[115,114,99,47,119,101,97,116,104,101,114,114,101,112,111,114,116,95,99,104,101,99,107,46,101,114,108]},{line,81}]},{weatherreport_runner,'-run/2-fun-0-',2,[{file,[115,114,99,47,119,101,97,116,104,101,114,114,101,112,111,114,116,95,114,117,110,110,101,114,46,101,114,108]},{line,54}]},{erlang,apply,2,[]}]}} 17:38:31 make: *** [Makefile:322: weatherreport-test] Error 1 17:38:31 make: Leaving directory '/home/test/workspace/CouchDB-ant_rhel/couchdb' 17:38:31 make: *** [Makefile:157: check] Error 2 17:38:31 Couchdb built succesfully

Whats the exact algorithm to calculate the CouchDB revision number. CouchDB uses a deterministic algorithm to calculate the document revision number. Here is one relevant doc I found: https://stackoverflow.com/questions/5954864/how-does-couchdb-calculate-the-revision-number Buts its all in elrang, I am trying to implement it in dart. I use sample document : {"_id":"123-this-is-an-id","hello":"world","testing":123} for testing. When I do the MD5 hash of it , its gives me : f0853833850bce08dce0896e010a375e, where as the couchdb revision number is : "_rev": "1-43dce8fe7e9a26b49390e3727a015cc0" I google it everywhere, but if I can find the algorithm some where in text , UI can convert it into dart.

I'm using Couchdb v3.0.0, and testing the browser GUI. I have created users in the database "_users", and have also assigned a role to that user. I have tested by getting related documents via curl or browser with that user on a particular database with no problems. But if I want to login to the browser GUI with that user, it will just keep loading in the "databases" section. Choosing other sections will also be prompted "You are not a server admin" in 1 step or 2. The above happens regardless if the tester account has been assigned member or admin access, neither of them can use the browser GUI to browser documents inside the database. Is it true that the browser GUI is only usable by admins (which are defined in the local ini files)? or am I missing anything?

In database context, I have come across **horizontal scalability** as one of the advantages of the NOSQL databases. What does the term mean? - CouchDB on Wikipedia - NoSQL on Wikipedia How would it compare to **vertical scaling**?

We are currently investigating database options for distributed database (possibly globally distributed) where the data in general is stored in "cloud" (this would not be a special requirement). The special requirement is that a parts of the database must be also available in local branches. Data added in local branches should be replicated (delay is not a problem) to the cloud and changes made in the cloud should be replicated back to the related database in branches. So a multi-master setup. Focus in on partition tolerance. It is possible that the local branches have from time to time no network connectivity or a slow network. So the database in the branches should be able to work by themselves and sync data and changes back. We are long to solve this problem on the database layer. One database for cloud and local branches. The only database that I came across to solve this problem is CouchDB with providing the "AP" of the CAP theorem. Are there any database available (I checked options like Elasticsearch, Crate, ArangoDB etc.) that play in the same area ("AP")? Requirement is that we must be able to install the database on-premise in local branches. For the "cloud" part I could image using a SaaS or do the hosting ourselves. Options like Postgres or MySQL with related replication options are not of interest here.

I work well with graphql environment, and I need to use couchdb, but his api with uris like rest api, it's for me a little old way to retrive data. Is possible to use graphql with Couchdb ? or there are plans in the future ?

I'm currently working on a wiki-esque application using CouchDB and am trying to implement a document versioning scheme. The way I see it there are two ways of doing this: 1. Store each version as a separate document 2. Store older versions as attachments to a single document. Right now, I've got a form of #1 working. When a user edits a document and saves it, the back-end first copies the previous revision to a new document and then saves the new version. Each document has a 'history' array that contains data on each version (the document _id of the old version, a timestamp, the editor, etc.). Since this history array could get pretty lengthy for a frequently updated document, I have a view that fetches a document sans history during a normal read (and another view for fetching the history). My question is this: I feel uneasy about my current approach and have been thinking about changing to the 'attachment' method. But I'm not sure. I'm hoping someone who knows CouchDB better than I (I've only been at this for a couple weeks -- and this is my first project using CouchDB... and NoSQL) can tell me what the pros and cons are of each approach. Or is there perhaps some other versioning scheme that I'm overlooking?

I was exploring couchbase backup and restoring procedures then we found standard procedures. But, if I can take data directory backup in the form of .tar and untar data directory whenever restore required, will it work? tar -cvf /opt/couchbase/var/lib/data -----backup tar -xvf xxx.tar ----restore

I need to run compaction on a production CouchDB instance, that may not have had compaction run on it before. If compaction puts too much additional load on the CouchDB instance, is it possible to safely kill the compaction process? If so, how?

The _membership endpoint in CouchDB (http://user:pass@domain:5985/_membership ) returns the following json to me: { all_nodes: [ "couchdb@n1.domain.me", "couchdb@n2.domain.me", "couchdb@n3.domain.me" ], cluster_nodes: [ "couchdb@n1.domain.me", "couchdb@n2.domain.me", "couchdb@n3.domain.me" ] } When would all_nodes NOT be the same as cluster_nodes? I managed to setup a cluster incorrectly when building CouchDB from source - there were 3 nodes in 'all_nodes', but none in 'cluster_nodes'. An answer points to the Server Fault question BigCouch all_nodes vs cluster_nodes , where using BigCouch the question author found _membership returned a list of cluster_nodes but nothing in all_nodes. (So similar to the question I'm asking, although opposite to what I've seen where only all_nodes had values). I don't understand the answer: > I just heard from Robert Newson on IRC that BigCouch nodes are connected lazily. Because: 1. I thought I read in CouchDB somewhere that nodes to be online at the time they are added to a cluster; and 2. This is at best one reason why there may be differences in the all_nodes and cluster_nodes results. I'm effectively asking why there are 2 fields for what seems to be the same thing in CouchDB 2.x? My (very limited) experience is that a cluster that shows nodes in the all_nodes field but not in the cluster_nodes field doesn't work. It's either not an answer to this question, or so far above my level that I don't understand it.

I am doing some testing with CouchDB. I downloaded the CouchDB application on my Mac and ran it - it opened in my browser, I verified, created a database, added docs ... then I closed the application. Next time I opened the CouchDB application, it opened a screen with the side menu but no other content (see attached image) and proceeds to open a new and identical tab every 5-10 seconds. The only way I can stop it is by closing the CouchDB application. Any ideas about what is going on here?

Are there any SQL server variants (i.e MySQL, Postgresql etc) that handle replication as well as couch db does and offers client side replication (2 way)? I'm in the early stages of my app which is currently using PouchDB / CouchDB as a key point about the app is being able to go offline then replicate when back online. I know the servers themselves can replicate but I'm basically looking to have an offline version of the database available to the client as well (which is what PouchDB / CouchDB achieves).

Is it possible to validate the data before it is entered into couchbase? I did not find any documentation confirming this. But I believe there must be some way to do it.

I have 80.000.000 Entries about Persons. They are built up like: Max;Mustermann;Examplestreet;50;9900;City 88000 is one ZIP Code, 8800 Zip Codes exist. I want to find out the entry based on Street/Housenumber/ZIP/City as fast as possible. **The idea:** Setting up 88 Databases for the first 2 numbers of the ZIP code. In this case its 99. In the Database i use the first 2 letters for the Street selection and create a table for that. In this Case EX. If i assume that the DB 99 has max 2.000.000 Database entries, EX will maximum have 100.000. How can i find entries fast in this 100.000 ?