Сколько лет опыта работы с PostgreSQL

Что проверяют

В инфраструктурной роли за этим вопросом стоит не SQL, а эксплуатация: переживёт ли база с вами отказ узла, обновление мажорной версии и потерю диска. Число служит поводом уточнить, что именно вы делали руками и что настраивал кто-то другой.

Как отвечать

Назовите срок и сразу перечислите зоны ответственности, которые действительно ваши.

• установка и параметры: shared_buffers, work_mem, max_connections, max_wal_size, настройка autovacuum под нагрузку;
• репликация: потоковая с слотами, synchronous_commit и цена синхронного режима, логическая для переездов между версиями;
• отказоустойчивость: автопереключение через Patroni, точка входа для приложения, поведение при разделении сети;
• бэкапы: pg_basebackup плюс архив WAL, восстановление на точку во времени и регулярная проверка восстановления;
• соединения: PgBouncer в транзакционном режиме, лимиты, отдельная точка для миграций;
• наблюдаемость: pg_stat_statements, отставание реплики, возраст самой старой транзакции, раздувание таблиц и индексов;
• обновления: pg_upgrade или логическая репликация, чтобы простой был минимальным.

Если база управляемая, скажите прямо и назовите, что осталось вашим: параметры, пул, мониторинг, план восстановления и репетиция переключения. Самый сильный ход это рассказать про одну аварию и что после неё изменили в настройках или в регламенте.

Где спотыкаются

Приносят красивые цифры без метода: ускорил запросы на треть, держали сто тысяч запросов в минуту. Первый же вопрос про то, чем мерили и на какой выборке, заканчивает эту линию разговора, поэтому лучше говорить о том, что проверяемо.

Считают pg_dump резервной копией и ни разу не восстанавливались. Без проверенного восстановления и без архива WAL это не бэкап, а надежда, и собеседник это спросит.

Отвечают не про ту роль: рассказывают, как писали запросы, когда спрашивают про autovacuum, зацикливание счётчика транзакций, раздувание и исчерпание лимита соединений.