Hope the explanation below answers the question “why one should not worry about distributing (horizontally Shrading) JSON-documents explicitly across multiple-buckets? for performance consideration.”
In couchbase, JSON-documents, stored in a Bucket (which is nothing but a “Logical / Conceptual” organization of JSON-data and a logical Unit for Couchbase Operations) are implicitly “Horizontally Sharded” (Distributed) into 1024 number of “Virtual Buckets” ( ;the actual physical Buckets in RAM distributed equally across multiple nodes). Additionally …
… as the (high speed)" Indexes" can also be defined on these distributed (implicitly “Sharded”) JSON-Documents, therefore we can have all different “types” (“Tables”, in terms of Relatoinal Database) of JSON-Documents (Records) in a single “Couchbase (logical) Bucket”, without having to worry about performance-degradation. In couchbase terms, a “Set of similar Records” is not identified through a “Table / Entity” instead a document (record) can be associated with a “Set of Records” using an “Indexed” key in the Document, like “type” (type : Orders).
Use of Memory-optimized Indexes (in RAM) further ensures high throughput (Performance). These indexes are, in turn, implicitly distributed across multiple nodes in a cluster for high performance.
Moreover, one can take advantage of Multi-Dimensional Scaling (MDS) through which you can dedicate nodes in a cluster for “Indexing Services”, so that indexes can be optimally distributed across RAMs of nodes, for higher performance / throughput.
In short, a Bucket (logical bucket comprised of multiple physical Virtual Buckets) is designed to serve Big Data with ultra high performance.
In fact, a Couchbase Bucket (Logical / conceptual bucket) is not comparable to a “Table” in Relational database, in any way. However, it can be seen as a kind of a “conceptual / logical” (schema-less ) Document s Store.
Note: Being "Schema-less " is a flexibility and a power feature of NoSQL databases.