Масштабировать базу данных — самая сложная задача в инфраструктуре для миллионов пользователей. Один сервер не справится, поэтому данные и запросы приходится размазывать по множеству машин. Это называется шардированием (database sharding). Без него Postgres или MySQL не вывезешь за пару терабайт данных.
Проблема не в том, что мало мощностей. Есть фундаментальные ограничения. Вертикальное масштабирование (больше CPU, RAM) упирается в закон Universal Scalability Law (USL): ресурсы конфликтуют, и производительность перестаёт расти. Read-replicas помогают с чтением, но не спасают главное узкое место — write-ahead log (WAL). Все записи проходят через него, это единый бутылочный узел. Плюс резервное копирование огромной монолитной базы тянется часами.
Шардирование решает это радикально: данные делятся на независимые куски (шарды), у каждого свой primary. Например, 256 шардов по 4 терабайта — это уже 768 серверов (с учётом реплик). Но как заставить все эти 768 машин выглядеть для приложения как одна база с одним адресом подключения?
Тут нужен продвинутый прокси-роутер. В отличие от простого пулера соединений вроде PgBouncer, он должен понимать, какие данные на каком шарде лежат. При вставке строки он считает хеш от ID и отправляет запись в нужный шард. При чтении — или направляет запрос на единственный сервер, или, если данные размазаны (как в SELECT с BETWEEN), собирает ответы со всех затронутых шардов и склеивает их. Для этого внутри роутера живёт полноценный парсер SQL и планировщик маршрутов.
Конфигурация топологии данных задаётся в JSON — например, что таблица user шардируется по колонке id через хеш. Эту метадату держит роутер. Neki для Postgres и Vitess для MySQL работают именно так. Поскольку всё в тексте и JSON, AI-агенты отлично подходят для настройки.
Но один роутер на 768 серверов и миллионы запросов в секунду не справится. Нужно много роутеров (10 или 100). Трафик между ними распределяет Network Load Balancer (NLB). Приложение коннектится к одному адресу (mydb.pscale.com), DNS выдаёт IP балансировщика, тот направляет соединение на один из прокси-серверов, и дальше запросы идут к нужному шарду. Вся сложная логика скрыта от приложения.
К шардированию стоит переходить, когда данных становится больше нескольких терабайт — именно тогда упираешься в долгие бэкапы и узкое горло WAL. Vitess проверен годами на крупнейших базах MySQL, а Neki — его более мощная версия для Postgres от той же команды.