1. Тут я мабуть не так висловився, малося на увазi, що це неочiкувана поведiнка для тих хто не в темi, а взагалi то так це за стандартом SQL.
2. Згоден.
3. Там загубилася цифра у другому згадуванні значення MACADDR має бути MACADDR8. I вони займають по 6 та 8 байтiв.
www.postgresql.org/...​t/datatype-net-types.html

Десь ближче до лiта, бо зараз багато роботи навалилося, а розiбрати пiдкапотну частину потребує багато часу

Як я вже писав нижче, mysql все ж таки поки що бiльш популярний, але я планую трохи розглянути форки percona db та mariadb в другiй статтi. А Cassandra це трохи для iнших цiлей.

mysql все ж таки поки що бiльш популярний, але так я планував трохи розглянути форки percona db та mariadb в другiй статтi.

Згоден що обирати БД тiльки по розглянутим плюшкам недостатьно. Це тiльки перша частина, бiльш глибше я розгляну в другiй. Просто поспiшив з висновками.

лiнь тут нi при чому, просто бiльшiсть компанiй не потягне цiнника оракла i значить не вийде просто забути про iншi БД, навiть якщо оракл настiльки крутий. Треба пiдходити до вибору враховуючи багато факторiв.

Приклад про «зроблену з гівна і палок на Ардуіно якусь падЄлку» не дуже вдалий, але я розумiю, що десь в великих ентерпрайзах оракл з усим оцим обозом має сенс, але це ж не значить, що його треба скрiзь пхати

TimeScale DB це ж timeseries DB, бiльше про збiр метрик. Тому в деяких випадках вона краща, а в деяких не дуже пiдходить. Ну i це ж просто надбудова над Postgresql.

Дивний у вас пiдхiд, ви скрiзь пишете, що оракл найкращий, але коли вас просять хоча б один кейс навести де вiн найкращий, то ви просто кидає книжку читати. Невже, ви самi не можете жодного кейсу навести? Чи може ви просто крiм оракла, бiльше нi з чим i не працювали, тому i кейсiв нема. Але як можна тодi казати, що вiн найкращий, якщо ви iнших не бачили, дивно.

Так, а якi є кейси, де за домогою oracle можна легко зробити, а цими двома БД не можна або важко? Просто за таку цiну вiн має бути наголову вищий. Плюс багато тех гiгантiв юзають пг або мускул i не бачать в них нiяких проблем.

Я хотiв порiвняти 2 основнi БД, а про колонкові, nosql та iншi БД можна окрему статтю писати, тому поки без них

Я не думаю, що багато чого зможу описати з практичної точки та чимось вас здивувати, тому що мiй досвiд з хайлоадом був десь рокiв 5 назад, а зараз я працюю з невеликими об’ємами.

Згоден, це було проблемою, я хочу в наступній статті більш детальніше роздивитися postgresql під капотом і там проаналізую, чи щось покращилося в останній час, чи ні.
Щодо HOT оптимізації згоден, це не поганий кейс, але як я казав, треба вміти працювати з нею.

Я не працював з Oracle в продi, тому не можу за нього нічого сказати, але помiтив, що ви пропонуєте його у всіх комментах. Жодна БД не являється срібною кулею, тому для різних кейсів можут підходити різні БД. І навіть якщо в якомусь кейсі сподобається oracle, то це не значить, що я не буду розглядати інші БД.
Плюс в нього є великий мінус — це його ціна, яка для середніх компаній, може бути дуже великою.
P.S. ну і глянувши на коммент людини яка там працювала, то жах чесно кажучи news.ycombinator.com/item?id=18442637

Я не казав, що у postgresql mvcc краще реалізований, він більше наближений до оригіналу яким його замислювали ще в 80их роках, в нього є свої нюанси, той самий автовакуум, але якщо його вмієш готувати, то проблем не буде. Тому я в статті і вказував, що mysql легший в адмініструванні.

З наведеними кейсами частково погоджуся, тому що навіть не в хайлоаді, можна успішно використовувати postgresql, просто потрібен досвід.
Якщо підходити до вибору більш ретельно, то опис можливостей теж може вплинути на вибір, але це так це не основа.

Як я вже нижче писав в комментах, це в мене перша вводна частина, так би мовити показати різні синтаксичні плюшки в обох БД, в другій планую більше заглянути під капот: як працює mvcc у обох бд, які є нюанси з postgresql (типу autovacuum, hot оптимізації...), продуктивність і масштабування...
А що до ваших пунктів, то можу коротенько відповісти:
1. це більше про сторонні інструменти
2. CDC вже давно підтримуюють усі основні БД, в тому числі oracle та mssql, у Debezium э коннектори під усі ці БД
3. тут трохи складніше ніж просто підтримка стандартів sql, якщо починаєшь наповну використовувати БД, а не просто як звичайний CRUD, то потім з будь якої БД важко перейти на іншу.
4. про це планував написати в другій частині статті, а також трохи затронути форки mysql
5. деякі плагіни я трохи затронув у цій статті, але якщо зануритись в них, то можна декілька окремих статей написати, але я не думаю що цей пункт сильно вплине на вибір БД
6. про перформанс планую написати в другій частині
7. про сесюріті згоден, можна було б трохи описати як воно влаштоване в обох БД, але якось упустив цей момент.

Реалізація MVCC postgresql ближча до оригінального стандарту (en.wikipedia.org/...​rsion_concurrency_control), тому що зберігає старі версії рядків в основному сховищі (я не кажу що це краща реалізація, але вона ближча до оригіналу), тоді як mysql зберігає старі версії окремо в спеціальній області пам’яті undo tablespace (це вважається модифікованим механізмом mvcc). Так само і у oracle і mssql свої реалізації.
HOT вирішує частину проблем, але, на жаль, не всі його знають і вміють використовувати.

На зараз шардування та консистенсніть між нодами вирішуеться сторонніми рішенями. Самі кращі на ринку платні написані з нуля.

тут все залежить від моделі данних та кількості цих данних, щось можна порішати реалізацією з коробки, а для якихось кейсів краще ставити окремі рішення. Але в більшості випадків середніх систем вистачає функціоналу самих БД.

Основні задачі це швидкість та доступність в рамках конкретного географічного положння

Знову ж таки все залежить від потреб, але в мене в більшості випадків консистентність була одним з найважливіших факторів.

За об’ем також — те шо постгрес вміщуе терабайти не означае шо він нормально горизонтально маштабуеться шоб віддавати мільярдам користувачам одночасно

А у вас є приклади, коли постгрес не міг нормально масштабуватись на великих даних?

Згоден, можливо назва статті не дуже добре підібрана, але я хотів показати різні плюшки обох БД в першій частині, а в другій — більше зазирнути під капот і тоді можливо питання більше розкриється.