Postgres 9.1 срещу Mysql 5.6 InnoDB?

PostgreSQL е много по-напреднал, когато става въпрос за SQL функции.

Неща, които MySQL все още няма (а PostgreSQL има):

• отлагаеми ограничения

• проверете ограничения (MySQL 8.0.16 ги добави, MariaDB 10.2 ги има)

• пълно външно присъединяване
  MySQL безшумно използва вътрешно присъединяване с някои вариации на синтаксиса:
  https://rextester.com/ADME43793
  

• странични съединения

• Регулярните изрази не работят с UTF-8 (Поправено с MySQL 8.0)

• Регулярните изрази не поддържат замяна или подниз (Въведено с MySQL 8.0)

• функции на таблицата ( select * from my_function() )

• изрази за общи таблици (Въведено с MySQL 8.0)

• рекурсивни заявки (Въведено с MySQL 8.0)

• записваеми CTEs

• прозоречни функции (Въведено с MySQL 8.0)

• индекс, базиран на функции

• частичен индекс

• ВКЛЮЧВАЙТЕ допълнителна колона в индекси (напр. за уникални индекси)

• много колонна статистика

• пълнотекстово търсене в транзакционни таблици (MySQL 5.6 поддържа това)

• ГИС функции на транзакционни таблици

• EXCEPT или INTERSECT оператор (MariaDB ги има)

• не можете да използвате временна таблица два пъти в един и същ оператор за избор

• не можете да използвате таблицата, която се променя (актуализиране/изтриване/вмъкване) в подизбор

• не можете да създадете изглед, който използва производна таблица (Възможно след MySQL 8.0)

    create view x as select * from (select * from y);
  

• последователност на четене на ниво израз. Необходимо е напр.:
  update foo set x = y, y = x или
  update foo set a = b, a = a + 100

• транзакционен DDL

• DDL задейства

• ограничения за изключване

• магазин за ключ/стойност

• Индексиране на пълни JSON документи

• SQL/JSON изрази за път (от Postgres 12)

• видове диапазон

• домейни

• масиви (включително индекси на масиви)

• роли (групи) за управление на привилегиите на потребителите (MariaDB ги има, въведени с MySQL 8.0)

• паралелни заявки (от Postgres 9.6 )

• създаване на паралелен индекс (от Postgres 11)

• дефинирани от потребителя типове данни (включително ограничения за проверка)

• материализирани изгледи

• персонализирани агрегати

• персонализирани функции на прозореца

• правилен boolean тип данни
  _{(третирането на всеки израз, който може да бъде преобразуван в число, различно от нула, като "true" е не правилен булев тип)}

Когато става въпрос за пространствени/ГИС функции, Postgres с PostGIS също е много по-способен. Ето едно хубаво сравнение.

Не съм сигурен какво наричате „лесна употреба“, но има няколко модерни SQL функции, които не бих искал да пропусна (CTE, функции за прозорци), които биха дефинирали „лекотата на използване“ за мен.

Сега PostgreSQL не е перфектен и може би най-отвратителното нещо може да бъде да настроите ужасния VACUUM процес за тежка база данни за запис.