Гайд по Postgres советовал стартапам сперва нормализовать схему. HN сказал: сначала — мониторинг

Гайд, выстроенный в три уровня с реальными порогами

Гид по выживанию в Postgres от Hatchet выстраивает советы как прогрессию: сначала базовая гигиена схемы и запросов, затем оптимизация запросов и обслуживание среднего уровня, в конце — продвинутые техники масштабирования. Это не абстрактные советы: к каждой рекомендации привязаны конкретные цифры. Последовательные сканирования начинают становиться реальной проблемой примерно после 20 000 строк. Прогоны autovacuum дольше часа сигнализируют, что настройки вакуума пора менять, пока раздутие мёртвых записей не догнало таблицу. Гайд настаивает на использовании первичных ключей, timestamptz и identity-колонок с первого дня; на CREATE INDEX CONCURRENTLY для любой достаточно крупной таблицы, чтобы построение индекса не блокировало запись; на коротких транзакциях, минимизирующих конкуренцию за блокировки строк; и на пакетной вставке, которая, по заявлению гайда, способна дать примерно десятикратный прирост пропускной способности по сравнению с построчной записью. Для советов на большем масштабе гайд рекомендует партиционировать данные временных рядов, чтобы autovacuum мог управлять партициями независимо, а старые данные можно было мгновенно отбрасывать вместо построчного удаления, плюс использовать триггеры с пакетным бэкфиллом для миграций больших таблиц вместо одного долгого ALTER TABLE.

Сбой, который гайд недооценивает

Самое содержательное возражение в треде на 181 комментарий пришло от комментатора, работавшего в стартапе, зависимом от Postgres, на ранней стадии: «Думаю, этому посту не хватает внимания к мониторингу и алертам. У Postgres есть несколько ключевых режимов сбоя, которых нужно всеми силами избегать, и алерты дают раннее предупреждение, что вы приближаетесь к опасности». Его конкретный пример: AWS присылает письмо, когда база данных приближается к transaction ID wraparound — по-настоящему катастрофическому режиму сбоя Postgres, при котором внутренний счётчик транзакций базы исчерпывает пространство и может увести базу в офлайн ради защиты целостности данных. «В стартапе это письмо с очень большой вероятностью пропустят, особенно если его прислали на Рождество. Нужно, чтобы всё, за чем следит AWS ради этого письма, было подключено к пейджеру». Дело не в том, что советы гайда по схеме и индексации неверны: дело в том, что ошибки схемы деградируют производительность постепенно и дают время заметить проблему; wraparound и похожие сбои почти не предупреждают и способны полностью положить продакшн-базу, так что инфраструктура алертов заслуживает места выше стилистических решений по схеме, а не ниже.

Второй комментатор согласился с отправной точкой самого гайда: «в заслугу статье, она действительно начинает с нормализации и дизайна!», при этом отметив ту же подспудную проблему, на которую указывает критика wraparound: нормализацию недооценивают на практике по всей индустрии, а не только в этом гайде, потому что «мы даём ORM строить» схему по умолчанию, и никто не пересматривает её, пока проблемы производительности не заставят.

Разрыв между тем, чему учит гайд, и тем, что ломается в продакшне

Вопрос о стратегии резервного копирования, поднятый в другой части треда, следует той же схеме: один читатель спросил, не должны ли бэкапы быть одной из самых первых вещей, которые настраивает любая команда, считая высокую доступность более поздним «приятным дополнением», а бэкапы — обязательными с первого дня, как только появляется продакшн-база. В сумме критика гайда Hatchet в треде не в том, что технический контент неверен: это спор о порядке: гайд, выстроенный вокруг уровней производительности (схема → оптимизация → масштаб), читается естественно для инженера, но реальный порядок, в котором стартапы обжигаются на практике, ближе к (бэкапы → алерты → всё остальное), потому что режимы сбоя, убивающие компании, — это не медленные запросы, а те, за которыми никто не следил, пока чинить их тихо было уже поздно.