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?

  • 2
    While I can't speak to the performance impact at all, the system you are using is "spiritually" in line with CouchDB. Storing previous versions as a response hierarchy is idiomatic, as it is in the "spiritual ancestor" of CouchDB, the Lotus Notes document database (NSF) (Damien Katz worked deeply on the one before developing the other, keeping and improving the best of it while tossing the cruft and backward/bugward compatibility requirements, so many of the more basic structural questions will have answers in Notes.)
    – Stan Rogers
    Commented Oct 4, 2014 at 14:58

3 Answers 3


Storing only changes will be a good idea, because storing older documents as separate documents or attachments to the final revision of database will create an overhead to database server.

When ever you change a key value in your document, add a new key named _h_i_s_<key_name>. In the newly created( or created during last update), append objects like below after every edit/update:-

key_name: "Hello",


    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],

This approach will save a lot of disk space and replication bandwidth in long run.


Without any knowledge of CouchDB. Storing every version though may only differs marginal from its predecessor is a waste of storage. I'd recommend storing changes only.

You might want to take a look here or search for data versioning.

  • This answer fails to say which of option 1 (separate documents) or 2 (as part of document) is better.
    – binki
    Commented Jan 19, 2017 at 16:16

years later ;-)

you do not have to store the changes because CouchDB will do that for you. If a document is changed, a new revision will be created. Be aware that this is physically another document with the same _id but a new _rev (revison) and will consume space on your disk.

For sure you would have to keep all revisions what would mean, that you need a very large disk.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.