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



