смысл эпитета "большие" здесь совершенно неуместен, ровно как и ожидание того, что у каждой компании, использующей PostgreSQL, в штате есть несколько человек, умеющих:
- правильно описывать нежелательное поведение
- обосновывать факт нежелательного поведения
- сопоставлять свои наблюдения с кодом (кстати, только этот пункт и следующий дают хоть какое-то преимущество опенсорса над коммерческими продуктами)
- каким-то образом делать собственные исправления
- продвигать свои исправления в апстрим

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

Максим,

вы когда пишите "комьюнити поддержит", "форки - вендор-лок", "ДИТ - стрелочники", вы выражаете свое личное беспристрастное мнение, или таки подобные высказывания связаны с вашей трудовой деятельностью (вот на оракловом форуме присутствует персонаж из Форса, он при каждом удобном случае спрашивает куплена ли поддержка, хотя здесь очевидно, что на форум люди приходят за помощью и финансовые вопросы в их компетенцию не входят)? Не может ли случиться так, что завтра вас перекупит условный EDB или PostgresPro и вместо подписи "лучшая поддержка PostgreSQL: dataegret.ru" мы будем иметь возможность лицезреть что-то в духе: "PostgresPro - лучший форк в мире"?

Давайте вот разберемся чтоли со всеми этими "маркетинговыми" заявлениями...

про вендор-локи

я последний раз, если не вру, слышал эту страшилку лет 15 назад, пытаться ее продвигать сегодня - откровенный моветон:
- компании прекрасно мигрируют между разными СУБД (тут главное вовремя убрать старперов и упоротое ИБ, топящих за БЛ в БД) - тот же убер тому пример Время жизни современных IT-систем довольно короткое, чтобы думать о вендор-локах
- если у форка есть дополнительные возможности, которые экономят время и ресурсы, то почему не взять и не воспользоваться ими прямо сейчас? Ну есть кастомные расширения - выпустили новый релиз, перелили данные, потом переехали на ванильную версию, в чем вообще проблема-то? Тот же PostgresPro заявляет что у них есть мониторинг, инкрементальные бэкапы и мульти-мастер - зачем сидеть на ваниле и жрать кактус (хотя если ваши утверждения связаны с трудовой деятельностью, то вполне понятно откуда они идут)?
- если архитектор решил использовать PostgreSQL - разве он уже не попал в этот вендор-лок? Неужели для того чтобы разрабатывать приложение работающее с PostgreSQL не нужно учитывать "особенности" этой БД?
- вы "врага" ищите совсем не так - это не EDB или PostgresPro, а Amazon и Dell

комьюнити поможет

Опенсорс согласно идеалам RMS уже довольно давно таковым не является, у абсолютного большинства опенсорс-решений наблюдается две модели:
- это мой пет-прожет, созданный исключительно для поднятия ЧСВ - стороннее мнение меня не интересует
- первая доза бесплатно - дальше уже за деньги

Сейчас, когда я оцениваю возможность затащить в проект стороннюю опенсорс библиотеку, я рассматриваю следующие факторы:
- номера версий: если там что-то начитается с 0, то это означает что сам автор не считает ее стабильной
- более-менее вменяемый выпуск релизов: не должно быть такого что нужно брать, откуда-то выкачивать исходный код и самому собирать
- наличие открытых ПР: если автору пытаются всеми силами помочь, а он эту помощь игнорирует, то он однозначно невменяем
- правильное движение багов/фич в багтрекере: по крайней мере должна присутствовать классификация и приоритезация

Что из этого мы имеем в случае PostgreSQL? ну вот:

5.3. Where to Report BugsIn general, send bug reports to the bug report mailing list at <pgsql-bugs@lists.postgresql.org>;. You are requested to use a descriptive subject for your email message, perhaps parts of the error message.

Another method is to fill in the bug report web-form available at the project's web site. Entering a bug report this way causes it to be mailed to the <pgsql-bugs@lists.postgresql.org>; mailing list.

If your bug report has security implications and you'd prefer that it not become immediately visible in public archives, don't send it to pgsql-bugs. Security issues can be reported privately to <security@postgresql.org>;.

Do not send bug reports to any of the user mailing lists, such as <pgsql-sql@lists.postgresql.org>; or <pgsql-general@lists.postgresql.org>;. These mailing lists are for answering user questions, and their subscribers normally do not wish to receive bug reports. More importantly, they are unlikely to fix them.

Also, please do not send reports to the developers' mailing list <pgsql-hackers@lists.postgresql.org>;. This list is for discussing the development of PostgreSQL, and it would be nice if we could keep the bug reports separate. We might choose to take up a discussion about your bug report on pgsql-hackers, if the problem needs more review.

If you have a problem with the documentation, the best place to report it is the documentation mailing list <pgsql-docs@lists.postgresql.org>;. Please be specific about what part of the documentation you are unhappy with.

If your bug is a portability problem on a non-supported platform, send mail to <pgsql-hackers@lists.postgresql.org>;, so we (and you) can work on porting PostgreSQL to your platform.



Ребята, те же Atlassian и JetBrains приюят ваш pgsql-sql@lists.postgresql.org совершенно за бесплатно, при этом еще помогут все смигрировать, лишь бы где-то в незаметном месте красовался их логотип, зачем вы заставляете пользователей вашего продукта постоянно страдать? (тут возникают довольно нехорошие мысли, что все что происходит, оно происходит вполне намеренно - заказывайте лучшую поддержку PostgreSQL)

bug vs feature

у бизнеса не существует понятия "feature", там либо продукт работает как нужно и помогает приносить деньги, либо не работает как нужно и бизнес терпит убытки - другого не дано, вы же как баги классифицируете исключительно порчу данных и всякие SIGSEGV, а все остальное - это либо "работает как ожидается", либо feature/design gap - здесь полная Ж, даже не касаясь родовых травм PostgreSQL, я могу в деньгах описать сколько стоит заказчику невозможность сделать create or replace force view как в том же оракле

Сорян, я прочитал кто есть кто:

https://dataegret.ru/#team Глава отдела консультирования и Сооснователь

Максим начал свою карьеру в 1999г. с работы над высоконагруженными проектами в Fujitsu, HeadHunter, Rambler и .masterhost и стал авторитетным мировым экспертом в PostgreSQL.

Максим основал Data Egret вместе с Ильей Космодемьянским, и взял на себя техническую часть бизнеса, оказывая поддержку нашим клиентам в решении особенно сложных задач, осуществляя консультации по архитектуре и иным вопросам.


Больше вопросов нет.