YugabyteDB’s automatic sharding overcomes PostgreSQL’s partition key limitations by allowing date range queries without modifying table partitioning. Thanks to its global secondary indexes, which don’t require a shared sharding key, YugabyteDB enhances performance by distributing rows across multiple servers. Discover the full advantages and see step-by-step instructions in our latest blog post.
Learn how YugabyteDB handles node loss and recovery to ensure consistent, continuous availability. With features like a 3-second leader re-election process and a robust fallback mechanism, your cluster can tolerate disruptions and resume optimal operation efficiently.
In YugabyteDB, you can manage the number of shards (tablets) using flags like ysql_num_tablets for total control or ysql_num_shards_per_tserver for control per tserver. Dynamic auto-splitting is also supported for automatic adjustments as data grows.
YugabyteDB supports two methods of sharding data: by hash and by range. Discover which strategy is correct to use in which situation.
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.
Setting the number of shards/tablets in your YugabyteDB cluster is dependent on your table size and activity, and while it is hard to gauge the exact number, here are some high-level suggestions.
Some data model choices in distributed databases cause data to grow in one node before it moves to another node. This will cause one node to become a hotspot for reads and writes. This article explains how to avoid that.
Explore how database sharding works, how to handle corner cases correctly, and how to split tablets to save resources.
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,
…