CouchDB and document versioning

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:

• Store each version as a separate document

• 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?

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_. In the newly created( or created during last update), append objects like below after every edit/update:-

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

or

{
    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.

StackExchange Database Administrators Q#78949, answer score: 2