Less bucket is better : no point with that, but on the other hand it can be interesting to split your data across different buckets if you plan to use views.
The way we understand it is that all views from a same designDoc will need to fetch from disk all the items of the Bucket they belong to.
Stupid demonstration : If you have a small set of items frequently inserted or updated, and a service critical view frequently accessed (stale=false) that map/reduce those items, you should better store them in a dedicated bucket rather than mix them up with the (maybe) million other items that the view doesn’t need.
More over, you will not fill up your FS cache with the unnecessary items, and will make access to disk data more effective.
By the way (TGrall if you hear us …) : How do we know that we are having to much buckets and would get some benefit from merging data in fewer buckets ?
eg : How can we trace the different beam.smp actions (stats, compaction, indexing, etc …) and calculate a per bucket overhead ?