Не страшно. Но все зависит от контекста. Есть ситуации, где норм. По логике вещей

Спасибо

> Самый популярный вариант - это pgpool-2

Эээ.... нет?! IMNSHO, у тех кто выбрал pgpool-2, уже какие-то необычные потребности. ;)

> мастер с read репликами

И он в PostgreSQL может быть неконсистентен, кстати (к счастью, на практике это редко случается).

> А как решается проблема что данные могут отставать от мастера?

Например, никак. ;) Цель-то у вас там какая, зачем это всё нужно?
А так — есть синхронная репликация, если нужно больше уверенности в том, что меньше данных потеряется, если что.

Смотря с какой целью...
Но даже если с "правильной" — дело тут в том, что все альтернативы тоже "так себе" (по крайней мере, не без объективных недостатков).

Слишком расплывчато: если бизнес хочет постоянно добавлять атрибуты к сущности (ведь таблица это какая-то бизнес-сущность), и никогда не удалять, то да, можно отдельными полями в таблице. (не забывайте только имена говорящие колонкам давать, а то часто бывает col1, col2 ...) Если будут удалять, то лучше в отдельную сущность (таблицу)
Ах да! и если это одна таблица на все приложение

> Я правильно понимаю, что с точки зрения оптимизации запросов лучше именно в основной таблице добавлять поля

Нет. Это же зависит от самих запросов.

> зато запросы выполняются оптимальнее, без лишни join'ов

Почему Вы думаете, что JOIN-ы уменьшают "оптимальность"?

> Просто самих свойств мб много и я вот думаю, стоит ли вынести в отдельную таблицу

А "логические" обоснования для их вынесения туда есть?
Я к чему — если подобные мелочи заставляют задумываться о производительности (если это не преждевременная оптимизация, как зачастую бывает) — может, там на самом деле [остро] не хватает "железа", и эту проблему нужно решать?

подскажите как собрать пг с контриб модулями но без документации

Если это есть/нет, то можно использовать массивы, каждому из свойств поставив в соответствие число.
А) {10,34,65} - есть свойства с этими номерами, остальные отсутствуют, неопределённости не предполагаем.
Б) если нужно «не известно», то можно хранить явное «нет» как отрицательное число. {-5,10,34,65}.
Будет намного быстрее сцепления таблиц.

Если не любите числовые (читай - магические) коды - можно объявить перечисление и хранить более понятные человеку значения.

Не подразумевает. Насчёт идиоматики ничего не скажу.

Нет, не подразумевает. И нет, неправильно, конечно.
И я бы на Вашем месте подумал над вопросами, которые я задавал выше. ;)

> Ну, явно проще, чем если бы их не нужно было прописывать.

Это да. Тут могут помочь views, но они не без своих проблем ("мешают" менять структуру участвующих таблиц; и для того, чтобы на нетривиальных можно было использовать DML, придётся писать триггеры).

> Просто потому что "SELECT + JOIN" тупо сложнее/комплекснее, чем обычный "SELECT"

Но может быть так же "тупо" намного быстрее. ;)

> Пытаюсь понять, как написать правильно

В описанном я не вижу "логических" оснований для выделения таких полей в отдельную таблицу(ы), по крайней мере.

> теперь стараюсь думать

Так можно думать дни напролёт, а "в продакшн" тем временем ничего не внедряется (я намекаю на KISS, если что). ;)

Читай про нормализацию БД, веб макака)
Так же есть json, это касается "добавлю столбцов".
Все разговоры про производительность,чаще всего, чушь, если не было тестов.

Ребятушки, на собеседование скоро иду, есть где список терминов, которые нужно повторить по БД ?
Типа индексы кластерные обычные и т.п.

Собеседование - это не экзамен, так что, если ничего не знаете, ваш путь - боль и страдания, унижение и отчаяние, да...

И самое главное - базы данных и термин "типичное" - антагонистичны до сих пор.

Понял)

Всё зависит от ситуации, как и всегда

у меня были случаи, когда 25 микро-запросов работали быстрее, чем 3 составных

а бывает и наоборот