Разработчик за пару дней собрал с ИИ CLI Terox для запросов сразу к 128 шардам PostgreSQL

Если у вас сотня шардов PostgreSQL, простой вопрос «на каком из них лежит запись?» превращается в квест: найти хост, вспомнить порт и базу, открыть psql, выполнить запрос, перейти к следующему. Бэкенд-разработчик, который раньше работал DBA, надоело это терпеть. Он сел рядом с ИИ и за пару дней собрал Terox — интерактивный CLI для шардированных кластеров.

Какую проблему решает

У psql и pgAdmin единица работы — подключение. В шардированной системе единица работы — целый набор подключений. Цикл на bash вокруг psql годится для разовой задачи, но как ежедневный инструмент разваливается: нет ограничения параллелизма, отмены запросов, сохранения ошибок отдельных шардов и защиты от случайного похода в production.

Terox вводит сущности уровнем выше: сервис → хранилище → один, несколько или все шарды. Хосты и базы задаются шаблонами, например pgbouncer-shop-rs{p1:03}.example.net раскрывается в 128 адресов. Запрос на all выполняется по всем шардам, результаты сливаются в одну таблицу с колонкой shard, а ошибки показываются отдельно.

Как это работает на примере

Команда \find items item_id = 424242 пробегает по шардам, показывает, что запись нашлась на shard_37, и сама переключает контекст на него. Никакого копирования хоста и угадывания.

Внутри всё сделано аккуратно. Параметр fanout_concurrency не даёт клиенту ударить по всем 128 шардам разом. Пул на шард создаётся лениво, у каждого шарда свой дедлайн, Ctrl+C отменяет выполняющиеся запросы. Чтение идёт в настоящей READ ONLY-транзакции PostgreSQL, а не по разбору текста SQL. Запись нужно включать явно через \write on, и при смене контекста она сбрасывается.

Отдельно сделаны диагностика (\activity, \blockers, \longtx, \sizes, \diff, \doctor) и линтер, который ловит DELETE без WHERE или NOT IN с nullable-значениями.

Миграции для редких случаев

Автор подчёркивает: обычные миграции уезжают вместе с деплоем. Terox нужен для исключений на больших нагруженных таблицах. Без флага --allowed команда \migrate работает как dry-run. Есть canary, батчи и --resume, а контрольная сумма не даст продолжить раскатку изменённым файлом.

Общей транзакции на 128 серверов нет, поэтому часть шардов может уже закоммитить изменения. Отчёт явно показывает частичное применение, и миграции должны быть идемпотентными. Для CREATE INDEX CONCURRENTLY и VACUUM, которые нельзя завернуть в транзакцию с SET LOCAL, Terox предупреждает о незащищённом выполнении и на production требует отдельное подтверждение.

Что это говорит про вайбкодинг

Цикл работы был такой: описать боль, найти минимальную модель поведения, получить реализацию от ИИ, проверить руками и тестами, превратить крайний случай в новый тест. Так появились закрытие пулов при выходе, история без паролей и тесты на гонки.

Главный вывод автора: ИИ так же быстро и аккуратно реализует ошибочную идею, причём сразу в двенадцати файлах. Поэтому сначала формулируйте инварианты: после выхода не остаётся соединений, read-only обеспечивает PostgreSQL, смена контекста выключает запись, частичная ошибка не выглядит как успех. Тогда разговор с ИИ становится инженерной работой.

Ограничения

Статический анализ в Terox — эвристика. Границы безопасности по-прежнему задают права роли, READ ONLY-транзакции, TLS и таймауты. Инструмент не заменяет мониторинг, бэкапы и понимание планов запросов и не исправляет архитектуру шардирования.

Практический вывод: если вы регулярно ходите по десяткам баз, оберните свой цикл в инструмент, который помнит правила за вас. А при работе с ИИ начинайте с инвариантов, а не с кода.