Postgres 9.1 vs Mysql 5.6 InnoDB?

PostgreSQL jest znacznie bardziej zaawansowany, jeśli chodzi o funkcje SQL.

Rzeczy, których MySQL wciąż nie ma (a ma PostgreSQL):

• ograniczenia możliwe do odroczenia

• sprawdź ograniczenia (MySQL 8.0.16) dodał je, MariaDB 10.2 ma je)

• pełne sprzężenie zewnętrzne
  MySQL po cichu używa sprzężenia wewnętrznego z kilkoma odmianami składni:
  https://rextester.com/ADME43793
  

• połączenia boczne

• wyrażenia regularne nie działają z UTF-8 (Naprawiono w MySQL 8.0)

• wyrażenia regularne nie obsługują zamiany ani podciągu (Wprowadzony z MySQL 8.0)

• funkcje tabel ( select * from my_function() )

• typowe wyrażenia tabelowe (Wprowadzony z MySQL 8.0)

• zapytania cykliczne (Wprowadzony z MySQL 8.0)

• zapisywalne CTE

• funkcje okien (Wprowadzony z MySQL 8.0)

• indeks oparty na funkcjach

• indeks częściowy

• INCLUDE dodatkową kolumnę w indeksach (np. dla unikalnych indeksów)

• statystyki wielokolumnowe

• pełnotekstowe wyszukiwanie w tabelach transakcyjnych (MySQL 5.6 to obsługuje)

• Funkcje GIS w tabelach transakcyjnych

• Operator EXCEPT lub INTERSECT (ma je MariaDB)

• nie możesz użyć tabeli tymczasowej dwa razy w tej samej instrukcji select

• nie możesz użyć tabeli, która jest zmieniana (aktualizacja/usuwanie/wstawianie) w podselekcji

• nie możesz utworzyć widoku, który używa tabeli pochodnej (Możliwe od wersji MySQL 8.0)

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

• spójność odczytu na poziomie instrukcji. Potrzebne na przykład:
  update foo set x = y, y = x lub
  update foo set a = b, a = a + 100

• transakcyjne DDL

• Wyzwalacze DDL

• ograniczenia wykluczenia

• magazyn kluczy/wartości

• Indeksowanie kompletnych dokumentów JSON

• Wyrażenia ścieżki SQL/JSON (od Postgres 12)

• typy zasięgu

• domeny

• tablice (w tym indeksy na tablicach)

• role (grupy) do zarządzania uprawnieniami użytkowników (MariaDB je ma, wprowadzony z MySQL 8.0)

• zapytania równoległe (od Postgres 9.6 )

• równoległe tworzenie indeksu (od Postgres 11)

• typy danych zdefiniowane przez użytkownika (w tym ograniczenia sprawdzające)

• widoki zmaterializowane

• agregaty niestandardowe

• niestandardowe funkcje okien

• właściwy boolean typ danych
  _{(traktowanie dowolnego wyrażenia, które można przekonwertować na liczbę niezerową jako „prawda”, nie właściwy typ logiczny)}

Jeśli chodzi o funkcje Spatial/GIS, Postgres z PostGIS jest również znacznie bardziej wydajny. Oto ładne porównanie.

Nie jestem pewien, co nazywasz „łatwością użytkowania”, ale jest kilka nowoczesnych funkcji SQL, których nie chciałbym przegapić (CTE, funkcje okienkowe), które definiują dla mnie „łatwość użytkowania”.

Teraz PostgreSQL nie jest doskonały i prawdopodobnie najbardziej nieprzyjemną rzeczą może być dostrojenie przerażającego procesu VACUUM do bazy danych o dużym natężeniu zapisu.