Так нужно сразу втыкать перед постгресом connection pooler, это в принципе полезно, даже с точки зрения времени "открытия соединения" клиентским приложением. Тогда вас проблема создания процесса на каждое соединение в общем-то беспокоить не будет.

так а всё же какой БД планируете пользоваться. Для oracle ЕМНИП пофиг, для мускула тоже (почему тогда не maria хотя бы...), для PGSQL вариант не сильно хороший. Но есть те же докеры.
Чисто для разработки - пойдет. Держать боевое решение - не стал бы.
Есть вариант - отказаться от PGSQL и либо потратиться (MS SQL, Oracle), либо заюзать БД с другим подходом (Mongo, Arango, Rethink).

Ну и если программист не может в linux... то я бы советовал сменить программиста

а как программист pg вообще отличит linux/win там же все прозрачно для него?

никак, но программиста лучше сменить :))

Да какбе вообще любая серьезная СУБД под WIndows работает в среднем "хуже". Раньше, в первые времена внедрения поддержки Linux, MS SQL был исключением. Теперь, вроде бы, уже и он по крайней мере не хуже.

Троллинг не зачитан). Как минимум по процессам легко (адресация, используемые функции уровня ОС), нужные для компиляции либы, упомянутые нюансы с работой (просадки той же производительности в ряде случаев). API работы, конечно, отличаться не будет. Но вот многие драйвера/библиотеки могут не взлететь вот так прост для win в стеках (скажем, ну вот взяли вы ORM которая юзает какой-нибудь libev для реализации асинхронщины - руками собирать, а это квест не плохой такой).

Я бы советовал с предметной областью хоть чуть-чуть познакомиться.

Ну да, согласен. Windows не слишком хорошее решение для сервера не на стеке MS. Скорее это исключение. Ну или неосиляторам linux хочется странного)

какой троллинг? я говорил про sql разработчика, orm вот это все-это прикладник, совсем другой зверь.
и да я также как и вы считаю, что слон должен пастись в свободной саванне *nix.

не буду называть себя прогером, так скрипто-кодер на перле, если прогер не знает llinux -- то по каким-то причинам его кругозор ограничен, я не говорю, что он долен кодить из под linux, но  что такое linux и с чем его едят прогер знать обязан, иначе это недопрогер....

Для SQL разработчика и работа под windows/linux по сути не важна, если СУБД можно запустить или на сабже, или в контейнере/любимой ВМ.
Но, хорошая команда разработки должна стремиться к окружению близкому к "бою". Иначе может получиться "ой". Абстрагирование участников разработки от таких вопросов - плохо может сказаться на конечном общем результате (а ведь по нему и будут судить в целом о команде).
По сути SQL разработчика может устроить и удалённый сервер =).
Да, слон лучше всего чувствует на *nix. Рад, что вы согласны)

>Для SQL разработчика и работа под windows/linux по сути не важна, если СУБД можно запустить или на сабже, или в контейнере/любимой ВМ.

это ровно то,что я вам написал с самого начала, не знаю что вас так задело.

Ну есть ряд случаев, когда не должен. Скажем под всякие микроконтроллеры, QNX, декстоп-онли (для того же win или закрытые для оборонки). Не правильно вас понял. Наши мнения совпадают)

Ну я имел ввиду, что хороший программист должен работать на том стеке, который близок к серверу конечному. Если команда выбирает СУБД по принципу "я знаю, что в win с ней проблемы" - будет очень печальный результат вероятнее всего.

Должно быть недопонял вас, возможно

речь о том что у клиентов могут быть варианты (т.е. если у клиента стоит oracle будет использоваться oracle, если нет, то скорее всего Postgres)
mysql скорее до кучи, но насколько мне известно mariadb форк mysql. тут скорее момент опять зависящий от клиентских условий. На мой взгляд конечно отличия вполне могут быть  между mysql и mariadb, но уж покрайней мере в процессе разработки с большой вероятность будут юзать mariadb.

😀👍🏻

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

🤣👍🏻👍🏻👍🏻
записал в мемориз!