In YugabyteDB you can use sharding and partitioning, so it can be confusing. In this blog post, we explore the differences (and similarities) between them and when each should be used.
In YugabyteDB, every table and index is sharded across the cluster, with partitioning at the query level (YSQL) and sharding at the storage level (DocDB), enabling unique configuration concepts like row-level geo-partitioning.
A distributed SQL database provides a service where you can query the global database without knowing where the rows are. You connect to any node, without having to know the cluster topology. You query your tables, and the database will determine the best access to your data, whether it’s close to your client or geographically distant.
The organization of data, whether co-located or partitioned, is the most important consideration for high performance,
A distributed SQL database needs to automatically partition the data in a table and distribute it across nodes. This is known as data sharding and it can be achieved through different strategies, each with its own tradeoffs. In this post, we will examine various data sharding strategies for a distributed SQL database, analyze the tradeoffs, explain the rationale for which of these strategies YugabyteDB supports and what we picked as the default sharding strategy.