Движок PostgreSQL копирует обновлённую запись, а старую помечает, как удалённую. Новые транзакции пускаются на новую запись, а старая завершает обслуживание уже начатых транзакций. Как следствие, старые записи надо вычищать для чего и служит механизм VACUUM. Но при больших нагрузках и частых записях возникает проблема, так как процесс VACUUM более ресурсоёмкий чем чистка отдельной таблицы UNDO. Так же как следствие подобной организации работы с данными является разница в качестве работы репликации в этих базах и по сути невозможность master-master репликации для PostgreSQL. Если в 11 версии ничего не поменялось. Не смотрел её ещё.

In a nutshell...

Начиная с 10-й версии схему привели к общепринятому виду, убрав лишнюю цифру из версии.

То есть ещё очень не скоро и ещё не известно как эти новые типы себя поведут и сколько времени нужно на их отладку!

Текстовые поля вообще не нужно индексировать без крайней на то необходимости, даже для уникальности.
В вашем примере будет просто каша из многих не уникальных email.
В любом случае, нужно сообщить пользователю, что email-занят, так что проверять уникальеность Нужно вручную и индекс UNIQUE тут не нужен!

> Или, скажем, у меня есть timestamp и я хочу сделать индекс только
> по году и месяцу и только для тех записей, где стоит
> определенный статус.

И что мешает индекс на timestamp и статус указать?

> Или, скажем, я хочу сделать PRIMARY KEY uuid. Как, binary(16) и поворачиваем
> байтики? Очень удобно.

Ни понял ни что это ни в чём удобство. Примери у меня всегда только числа!

> Или, скажем, у меня есть таблица со структурой, где большинство полей null,
> и я хочу эффективно искать по любой их комбинации. Или JSON,
> по внутрянке которого я хочу искать так же эффективно. В постгресе
> у меня есть GIN и GIST на выбор. В мыскле... мммм...

Снова не понял в чём тут проблема искать нулы?

> ну, я могу формировать для каждого поля псевдо-слово типа _FIELD_A_IS_123_ и
> искать фуллтекстом, лол.

И снова не понял зачем это нужно и что это даёт?
Если нужен полнотекстовый поиск, то сфинксом сабж по производительности и рядом не стоял!

> Да можно долго перечислять.

Нет, Ваших высранных из пальцев примеров мне больше не нужно.

MySQL также можно подогнать под нужды и настроить там что угодно, хоть кэш отключить, хоть дать подсказки оптимизатору запросов, хоть свой движок написать. Но Вы считаете, что каждый пользователь сабжа занимается его тонкой настройкой?
Впендюривание костылей, да ещё и на этапе разработки, когда не понятен характер нагрузки...
Нет уж, нормальный, в моём понимании, программист на такое не пойдёт!
Это сабж, со своим вакуумом, "вот так работает", которому программную реапликацию совсем недавно завезли. Судя по вашим упоминаниям костылей, самостоятельно она нормально и не работает.
В MySQL можно выбрать и движок, под конкрерную задачу, и тонко настроить выделение памяти, и просто надёжную настроить репликацию (master-slave) и управлять ей. При этом координально изменить работу СУБД Вы всё равно не можете и для максимальной эффективности, Вы должны понимать как она работает в том числе и как работает PostgreSQL!
Я не говорил что сабж какащка. Я говорил что он и MariaDB созданы для разных целей, и для вэб-приложений, где единственный пользователь через сокет и не нужны вообще хранимые процедуры, и есть возможность применить MariaDB+Redis+Sphinx сабж будет хуже, как по быстродействию, так и по надёжности, так и по сложности проектирования и сопровождения.

кое-как добиться почти такой же производительности и надежности, как у mysql из коробки - если повезет с workload.
Поправил, не благодари.