С PostgreSQL и MySQL секс имел только в конце 90-х.

Сначала был выбран PostgreSQL, но он в _тот_ момент полностью не работал. Нужны были таблички в 45 000 записей + таблица связей в 2 миллиона - без vacum'а не работало, а vacum ставил клином сервер на 2 часла, что для I-net проекта было недопустимо. В общем, PostgreSQL с матерными словами пришлось выбросить на помойку, как студенческую поделку вообще не приспособленную к жизни.

Перешли на MySQL, в нем не было целого ряда "нужных фичь", но в конце-концов, то что не понимал MySQL сделал руками через temporary table. Но тогда My SQL так себя и позиционировал: быстрая недо-база в которой не реализованы сложные фичи или фичи снижающие производительность - т.ч. никаких обид )))

В современное время, я вижу реально работающие в продакшене СУБД PostgreSQL и понимаю, что его все же допилили до работоспособного состояния. Читая доки по PostgreSQL, складывается ощущение. что по "движку" он примерно приблежается к Oracle 8i.

Насколько "родовые травмы" PostgreSQL (vacum и работа через ФС) критичны для нагруженных систем в продакшене - не знаю. Но опасения у меня все же есть, т.к. на реальных проектах с Oracle (когда работали через ФС) я видел, когда ОС при full table scan запросе из таблички большей чем память на сервере, думала, что компьютер это файлопойка, раздувала кэшь файловой системы по максимому и все приложения отправлялись в своп. На Oracle выличилось "волшебным пендалем" админу и включением Direct IO. Что при таком патерне запросов нужно делать с PostgreSQL - я не знаю.

Все было бы хорошо, если бы хотя бы были вменяемые доки по настройке ОС + PostgreSQL. Но обычно доки по ОС - отдельно, доки по настройки СУБД - отдельно. Читаешь и понимаешь, что одно противоречит другому. Не говоря уж о том, что ОС-писатели тоже изгаляются как могут: например опцию swappiness в ряде ОС сделали деприкайтет и выпилили, оставив полное непонимание, что же использовать вместо нее (((

Не админ. Тупо программер. Т.ч. по многим пунктам знания устаревшние лет на 5-8 (((.