Изменение правила шардирования при масштабировании БД

При шардировании БД у нас есть несколько экземпляров СУБД, и код веб сервера выбирает с каким конкретно работать по какому-то правилу на основе айдишников записей. Например, у нас есть шардирование по userId, и каждый сервер БД содержит данные 4-х тысяч пользователей, то есть, сервер выбирает СУБД по userId // 4000. И однажды вдруг меняется логика, теперь по каждому пользователю надо хранить вдвое больше данных на пользователя. Вероятно, теперь надо хранить по 2 тысячи пользователей в каждом сервере БД... Но как изменить правило шардирования и мигрировать базы данных динамически, пока сервера активно обрабатывают запросы пользователей? Надеюсь, есть что-то помимо ручного поднятия новых серверов, настройки репликации туда и т.п, всё же у нас 21й век DevOps'a. И может существует какой-то архитектурный паттерн проектирования, который может быть реализован на этапе планирования системы для того, чтобы она была адаптивна и готова к таким событиям?

Возможно универсального решения нет, поэтому я буду рад увидеть подходы к решению проблемы для любых технологий. Основной интересующий стек – Python и Postgres, но будет здорово, если эта задача уже решена и автоматизирована хоть где-то, может в MongoDB или Cassandra.