3ton

что для REST серверов лучше Node не найти

это твой главный неправильный вывод, лучший будет тот, который написан на технологии, которую лучше всего знает исполнитель.

Например стриминговый сервер или сервер для чата, он же относится к разряду типичных запрос/ответ

еще одна большая ошибка, вообще всё смешал в кучу, "стриминговый" это больше про максимальный pull c сервера, "чата" это про полноценный обмен в обе стороны, а "запрос/ответ" это про базовый http и он для этих обоих случаев, очень невыгодная стратегия, поэтому для них в http написаны свои частные протоколы, например, websocket для нормальной реализации чатов.

Придется сделать 2 базы - оригинальную и после изменений.

После этого есть варианты:
Можно воспользоваться mysqldbcompare в режиме --changes-for

Или попросту сделать два дампа и сравнить их

mysqldump --skip-comments --skip-extended-insert -u user database1 > file1.txt
mysqldump --skip-comments --skip-extended-insert -u user database2 > file2.txt
diff file1.txt file2.txt

Ну или включить Audit Log в mysql и посмотреть по нему какие изменения будут вноситься.

+ https://liquibase.org/

+ Здесь в самом вопросе перечислено пяток инструментов https://stackoverflow.com/q/225772

И кажется Mysql Workbench может сравнивать.

Я вам несколько иначе постараюсь объяснить. Валидаций может быть 2 - серверная и клиентская.
Смотрите: когда мы говорим, что email - unique, мы же не передаем клиенту, в js-валидатор перечень всех занятых email-ов, такая проверка осуществляется уже на сервере, если на стороне клиента прошли другие валидации. Тоже самое и с собственноручно написанными php-проверками, они не трансформируются же в js-код и выполняются на сервере в момент вызова метода validate() модели. Поэтому самому для себя, для понимания, что происходит - откройте исходный код html-страницы с формой и посмотрите, какие правила валидации прописаны в js, это здорово поможет разобраться в ситуации.

Что касается решения проблемы, то либо используйте ajaxValidation, как вам уже написали выше, либо присмотритесь к валидатору Compare Validator. В вашем случае для email не прописано правило unique, следовательно могу сделать вывод, что подсветка зеленым инпутов происходит еще до отправки формы на сервер, т.е. серверная валидация не отрабатывает.

Храни в мускуле.

Файлы, действительно - самый неудачный вариант. Сара Големон, отвечая недавно на подобный вопрос, написала

File storage is only a default because the runtime doesn't know in advance what database engine or credentials you're going to use unless you tell it. So... ya know.... tell it.

То есть файлы - это от безысходности, и по-хорошему пхп бы хранил в базе, но просто не знает, в какой и как с ней соединяться.

Редис и мемкеш - это кэш, а не хранилище. Подумай над тем, что такое кэш и для чего он используется. И подходит ли кэш для хранения сессий.

Про скулиту ты все правильно написал. Те же файлы, вид сбоку.

А про мускуль очень смешно. Какая-то прямо повальная датабазебоязнь. Откуда это "я вообще хочу минимизировать запросы к MySQL"? Что за ерунда про "соединение может оборваться"? И как ты вообще можешь сравнивать по производительности файл на диске, который открывается при каждом запросе, с демоном, который держит все данные в памяти и отдает по сокету?

При выборе языка/фреймворка для бэкенда некорректно говорить о том, что один лучше, а другой хуже. Важна конечная цель. NodeJS может быть сколь угодно быстрее других при генерации простых веб-страничек, зато когда речь идет о работе с большими числами, то JavaScript проигрывает, потому что BigInt еще совсем сырой, а реализовывать вычисления со строками - такое себе развлечение. Я к тому, что выбор по одному критерию - не лучшая практика

location ~ ^/phpmyadmin/* {
    proxy_pass http://127.0.0.1:8080;
	 server_name_in_redirect off;
	 proxy_set_header Host $host:$server_port;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
}

<VirtualHost 127.0.0.1:8080>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

У нас в компании 4 энтерпрайзных проекта на Yii2. В том числе CRM. В том числе и связь с телефонией, 1С, баг-трекером. Всё работает отлично, без нареканий. О каких "слабых" местах вы говорите? Прекратите читать - начните делать!

Симфонисты не работают с yii2 и не до конца понимают о чем пишут :)
Я скажу так: оба фреймворка на высоте, по возможностям одинаковы, но подходы очень разные.
Объективно скажу так: на yii2 не получится запускать отдельные модули без запуска всего приложения, тут у симфони2 огромный плюс. Так же у симфони более классные консольные команды для генерирования каркасов, мне больше нравится, чем gii(но дело вкуса). Но по факту большинство сильных сторон симфони не оправдывается в связи с высоким порогом вхождения. Найти хорошего симфони программиста намного сложнее, чем найти его на yii2. Поэтому взависимости от бюджета и масштаба проекта можете выбирать. Симфони2 - это больше уровень корпораций, yii2 более простой при практчески том же функционале.
Если знаете симфони2, то лучше подтяните его. Yii2 изучить намного проще, намного всё прозрачнее внутри работает, там Вам хватит пару вечеров, чтобы пройтись по исходникам и всё для себя понять как изнутри как работает.