When upgrading from 2.x to 2.1.1, if you have not customized your node name in vm.args , be sure to retain your original vm.args file. The default node name has changed from couchdb@localhost to couchdb@127.0.0.1 , which can prevent CouchDB from accessing existing databases on the system. You may also change the name option back to the old value by setting -name couchdb@localhost in etc/vm.args by hand. The default has changed to meet new guidelines and to provide additional functionality in the future. If you receive errors in the logfile, such as internal_server_error : No DB shards could be opened. or in Fauxton, such as This database failed to load. you need to make this change.

The deprecated (and broken) OAuth 1.0 implementation has been removed.

If user code reads or manipulates replicator document states, consider using the [replicator] update_docs = true compatibility parameter. In that case the replicator will continue updating documents with transient replication states. However, that will incur a performance cost. Consider instead using the _scheduler/docs HTTP endpoint.

The stale parameter for views and _find has been deprecated in favour of two new parameters: stable and update . The old stale=ok behaviour is equivalent to stable=true&update=false , and the old stale=update_after behaviour is equivalent to stable=true&update=lazy . The deprecated stale parameter will be removed in CouchDB 3.0.

The new httpd/max_http_request_size configuration parameter was added. This has the same behavior as the old couchdb/max_document_size configuration parameter, which had been unfortunately misnamed, and has now been updated to behave as the name would suggest. Both are documented in the shipped default.ini file. Note that the default for this new parameter is 64MB instead of 4GB. If you get errors when trying to PUT or POST and see HTTP 413 return codes in couchdb logs, this could be the culprit. This can affect couchup in-place upgrades as well.

#914: Certain critical config sections are blacklisted from being modified through the HTTP API. These sections can still be modified through the standard local.ini or local.d/*.ini files.