Does multiple versions of couchDB keeps redundant data?

Question

I'm just started with CouchDB and noticed that it keeps multiple versions of data in the database. Does it mean that each version is a full copy of the fields currently added? So does it keep redundant data on the disk or the versions are just incremental versions?

Answer 1

CouchDB holds multiple complete revisions of documents, it does not store incremental changes. The internals of CouchDB use an append-only data structure, so each new revision is added to the database file.

In addition, CouchDB uses MVCC (multi-version concurrency control) which prevents the need for locks while allowing concurrent writers. (you can read more about this feature in their documentation) This is relevant because the revision numbers are an important part of that mechanism, and keeping some previous revisions aid in that process. (particularly for conflict resolution in a replicated setup)

In short, you will have duplicates in your database each time you modify a document. Thus, modifying the same document many times can lead to an inflated database file. In addition, very large documents with fewer modifications also have this same effect. For each document, only the latest version is considered "active" by the database, but old revisions may still be around. (more on that next)

This might sound inefficent and wasteful, but CouchDB has you covered with a feature called compaction. This process removes all revisions (except for the most recent) from the database file altogether. Prior to CouchDB 2.0, this was generally invoked manually by an admin, but now it is much more automated.

One common misconception about CouchDB is that the multiple versions can be used like a version-control system (eg: git, svn), so you can always keep some sort of historical record of your database. However, this is completely false, as MVCC is purely for concurrency control. As stated before, compaction removes the old revisions, so you should only depend on the most recent revision existing in your database at any time.

I would strongly recommend reading through all of CouchDB's official documentation. It is not especially lengthy, and quite excellent at describing the internals and the trade-offs you have available to you when deciding how to build your applications.