How to prevent CouchDB to create document revisions when updating simple counters

CouchDB is very explicit about the trade-offs it makes. In this particular case, we are talking about having a crash proof database that, sadly, can and will use a lot of disk until compaction.

You get with this reliability and a lot concurrency for reads. You will also get the ability to replicate seamlessly with any other nodes. This is the bacon of it. Having to compact because of bumped counters is the suck of it. Forget about mucking around with _rev_limit. You will screw yourself doing it because revisions are so foundational to Couch.

One possibility that you have is logging some info, the date and time, IP's and other stuff. You'd then create a view emitting the data you need and using _count as your reduce function. You'll get the info you need and some other possibly valuable stuff for analytics. This is the "just create a view" solution.

The second possibility would be using [redis] (http://redis.io/commands/incr). Redis is quite nice and would fit well with this use case (http://ai.mee.nu/is_couchdb_the_anti-redis). This would be the "the right tool for the right job" solution.

The third possibility would be to simply ignore it. It might not be a problem at all (if you compact often). This would be the "just relax" solution.

You have to take the good with the bad and make sure the advantages outweighs the disadvantages. Measure everything twice before you cut/optimize.

I don't think it's possible.

An alternative solution would be to place the counter in a small document, and run compaction on it periodically. This isn't optimal, but it minimizes the space occupied.

You may also want to consider using something like memcached (or Membase) to serve as your "counter storage". That will let you update these counters without creating extra revisions in CouchDB. I assume that you don't actually need to keep all of the intermediate states of the counter (since you say that you don't want the revisions kept around) so putting them in something better suited for this use case seems to make sense.