Вайбкодинг против сотни шардов: как я за пару дней собрал Terox
Когда сервис живёт на сотне PostgreSQL-шардов, даже вопрос «где лежит запись с таким ID?» легко превращается в обход десятков подключений. Сущности распределены консистентным хешированием, а редкие операции на нагруженных таблицах требуют отдельно следить за lock_timeout , statement_timeout и пулом соединений. Я бэкенд-разработчик высоконагруженных сервисов, в прошлом DBA. Штатные миграции у нас раскатываются автоматически. Но когда изменение требует отдельного контроля на нагруженной таблице, не хочется полагаться только на то, что разработчик проверил скрипт и ничего не забыл. Так за пару дней совместной работы с ИИ появился Terox — CLI, который ищет данные по набору шардов, переключается на найденный и раскатывает сложный SQL через dry-run, canary и батчи. Рассказываю, как рабочая боль превратилась в open-source инструмент и почему при работе с production-базами вайбкодинг быстро превращается в обычную инженерную работу. Приручить сотню шардов