I've been thinking about other algorithms as well, like range-based. We can definitely override the algorithm for hot shards. Ideally, we match what Postgres does with partitions: range, hash, and list. That way, we can shard both inside Postgres (e.g. with postgres_fdw) and at the proxy.

I think the first step is to add as much monitoring as possible to catch the problem early. There is also the dry-run mode [1] that you can try before sharding at all to make sure your traffic would be evenly split given a choice of sharding key.

[1] https://pgdog.dev/blog/sharding-a-real-rails-app#dry-run-mod...