This is a continuation of the article on the change-feed for Cosmos DB. Specifically, it discusses document versioning support.  If we treat each item in CosmosDB as a standalone document, then it is subject to the same versioning principles as a blob. The versioning for blobs automatically maintains previous versions of an object. When blob versioning is enabled, it can restore an earlier version of a blob to recover data to recover the data if it is accidentally deleted or modified. If a blob is edited, it copies on write so a new version is created. Since each write operation creates a new version, it is possible to revert to earlier versions. Similarly, an older version of the data can be promoted to create a new version. Each version maintains a new identifier. A blob can have only one current version at a time.  Blob versions are immutable.  The content or metadata of an existing blob pertaining to its version. If there are many versions for a blob, it will tend to increase the latency for listing operations. Fewer than a thousand versions are preferable for a blob. Old versions can be deleted automatically.

In the case of a blob, the version identifier is the timestamp at which the blob was updated. The version ID is assigned at the time that the version is created. Read or write operations can target a specific version given the version id. If it is omitted, the current version is used instead. The x-ms-version-id header in the http responses holds this identifier.

Versioning is not enabled on a per blob basis. It is set at the account level. Prior to versioning being enabled on the account level, a blob in that account does not have a version.  When the versioning is enabled, all write operations create a new version except for the put block operation.

When the delete operation is called, the current version becomes a previous version and there is no current version anymore. All the previously existing versions are preserved.

Blob versioning can be enabled or disabled. When it is disabled, no new versions are subsequently created. Any existing versions remain accessible.

Blob versioning is frequently used with soft delete which protects a blob, snapshot or version from accidental deletes or overwrites by maintaining the deleted data in the system for a specified period.  During this time, a soft-deleted object can be restored to its original before the delete was issued. After the expiry of the retention period, the object is permanently deleted.  This can be enabled or disabled at the container level. Attempting to delete a soft-deleted object does not affect its expiry time.

The API support for versioning and soft-delete is only available in later versions rather than the earlier versions. If a blob has snapshots, the blob cannot be deleted without deleting the base blob. No new snapshots are created. Soft-delete objects are invisible unless they are called out for displaying or listing.