Юрий Ярош

Там есть проблемы...

Надо костыли типа Slony или Stolon
Что бы миграции "расползлись" по кластеру как-то.
Для миграций можно liquibase c местным formatted SQL'ем.

Накатывать можно чем-угодно.

В принципе Postgres-XL уже потерял свою актуальность PG11 + stolon / pg_pathman хватает с головой, ещё можно Citus, но имхо он слишком толстый. Если надо map/reduce'ить - лучше план вручную написать.

yii1 морально устарел
yii2 дружит с PHP5.4 и вот только-только допиливается поддержка PHP7
В phalcon'e 2.1 уже есть рудиментарная поддержка РНР7, осталось только подаждать месяц-второй пока допишут.
В Symfony3 (тадам уже 3!) есть полная поддержка РНР7 ещё с предыдущего года.

Если начинать переписывать что-то на что-то РНРшное - нужно понимать что сейчас допилят РНР7 решения и всё автоматом устареет, или же отвалится из-за отсутствия обратной совместимости.

Желательно брать сразу симфонию и Sonata-Project бандлы - это будет идеальной заменой тому же WP.

Даже в случае с PostgreSQL'ем, СУБД имеют достаточно уровней инкапсуляции позволяющих разделять несколько табличных пространств и схем в рамках одной и той же базы данных.

Можно разделить все по каталогам, соответствующим базам данных, схемам и табличным пространствам - нет смысла хранить всё в одной базе, так же как и нет смысла заморачиваться с вездесущими табличными префиксами времён MySQL 3.

Зависит от конкретной версии PostgreSQL'я.
Если самый простейший - можно с коробки в 9.5 через postgres_fdw вот так . В <9.5 нельзя так как там внешние таблички (foreign tables) не могут наследоваться. Cам fdw afaik однопоточный по историческим причинам, по этому имеет смысл хранить сразу несколько шардов в пределе одного сервера.

Если нужна поддержка, и что-то попроще чем ванильный SQL, то лучше взять какое-то готовое расширение (extension) типа pg_shard, и потом докупить у них же их плюшки к PostgreSQL'ю по потребности. pg_shard умеет только операции равности (equality) хешей столбцов у шардов, эт значит что если выползти за границы таблички любым range query - оно начнёт бороздить все шарды, что порядком надоедает. Реализацию операций сравнения (больше/меньше) хешей пока не замечал, хотя давно его не ковырял. Т.е. хоть это и довольно таки простое решение, без понимания его ограничений чуть более чем наверняка можно напороться на квазилион граблей. Иногда складывается впечатление что разработчики специально затягивают feature list для того что бы клиенты переходили на их платный CitusDB.

Уууу.... CitusDB сегодня заопенсорсили.

PostgreSQL-XC нынче чуток морально устарел, и на его основе был разработан PostgreSQL-XL, про который уже упоминалось на хабре. Поддержки как таковой у него нет, но есть пару российских вендоров которые в нём перманентно ковыряются, так как это сугубо опенсорсятинка. Имхо, по функционалу оно на много превосходит pg_shard, и с ним нет таких дурацких проблем, хоть и разворачивается в разы сложнее, не без полуночного красноглазия.

Doctrine DBAL / ORM

Прежде чем холиварить нужно разъяснить 3 вещи
1. Модель БД в 6ой нормальной форме могут проектировать единицы
2. Понимать как все эти схемы, каталоги, представления и материализованные представления вписываются в SOA, как производить тестирование, какие функции где хранить, как проставлять тригеры, как подчищать журналы, как разделить представления чтения/записи в рамках CQRS - знают единицы, а использует на практике и того меньше.
3. PostgreSQL можно сделать быстрее и эффективнее чем MySQL / MongoDB / Oracle, но не наоборот, хотя косячить можно везде :), и там много чёрной магии которая простым смертным просто недоступна. PostgreSQL слишком просто кастомизируется, и этим можно получить просто дикие приросты производительности, особенно если речь идёт о внедрении каких-то кастомных типов данных, индексов и функций агрегации. В остальных решениях "шаг вправо, шаг влево - расстрел". Если вам нужно простое решение которое "лишь бы работало с коробки" - вам точно не стоит использовать PostgreSQL.

Нужно понимать что даже если хранить JSON в PostgreSQL под gin индексом, то это будет быстрее чем Btree в Mongo. Потому что using index with vodka ! JSON в PostgreSQL можно и не нормализовать, там есть flyweight шаблон, так что ничего лишнего он хранить не будет - посмотрите примеры работы. А вот в реляционных табличках какого-нить enum будет более чем достаточно, хотя я обычно не ленюсь, и создаю кучу табличек с id name +unique, и отдельным ts полем для поиска.