Handling hot shards

Neki addresses hot shards by allowing teams to adapt sharding strategies without downtime when uneven tenant growth, large datasets, or cross-tenant query requirements make an original shard key ineffective. Drawing on Slack’s Vitess-based evolution from sharding messages by workspace to sharding them by channel, it argues that tables should use shard keys aligned with their access patterns rather than relying on a single key for all data. Neki uses a declarative data topology to specify table shard keys and key ranges, making placement predictable and enabling resharding operations that copy existing data, stream ongoing writes, and switch traffic while applications remain available. Suggested responses to hot shards include temporarily scaling up an individual Postgres shard, isolating a large tenant into its own key range, or, as the more durable option, resharding selected high-growth tables by a more appropriate dimension. The recommended approach is to address the tables creating current bottlenecks incrementally, rather than waiting to redesign an entire database schema.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.