Roquie

На pgsql будет быстрее, естественно, но для системы в целом - базу лучше не нагружать лишней работой, которую можно выполнить и так.

То что касается выборки данных без ее обработки - сделать на простых процедурах в постгре
То что касается бизнелогики написать на том языке, на котором проще писать тесты

Переписывать несколько раз код придется вне зависимости от твоей квалификации

SELECT email,account,mobile_phone FROM users WHERE email = 'example@gmail.com' OR account = 'example@gmail.com' OR mobile_phone = 'example@gmail.com'

Попробовал сделать так, вроде работает

location /api2.php {
proxy_pass http://www.blabla.com/api.php;
}

А вы как думаете? Варнинги допустимы, но крайне не желательны. На то они и варнинги, иначе бы просто смысла в них небыло. Есть варнинги показывающие, что были использованы устаревшие средства языка, которых в новой версии уже может и не быть. Или какой-то метод устаревший, и при обновлении библиотек/php ваш код просто сломается.

Проблемы же "лишнего кода" решаются обертками и слоями абстракций:

// метод класса Request
function get($name, $defaultValue = null) {
    if (!isset($_GET[$name])) return $defaultValue;
    return $_GET[$name];
}

$isAjax = 1 == $request->get('ajax', 0);

Попробуйте symfony/httpkernel в качестве обертки и уровня обстракции для обработки запросов.

www.postgresql.org/docs/current/static/sql-creates...

Тем, что там можно писать мало там, где мы привыкли писать много. Подобный "конвеншн овер конфигурейшн" - он помимо прочего оставляет ощущение, что автор пишет не сферическую вещь в вакууме, которая якобы должна подойти всем, а для нас, для простых рабочих пацанов с окраин, со своими вполне конкретными юзкейсами. Т.е. он 1. человек умный и 2. знает жизнь. Это подкупает.

Например, в output идет то, что возвращено из контроллера, а если возвратить ORM-объект или массив (точнее коллекцию) ORM-объектов, то будет отдан json, причем со всеми связанными объектами. Масса нужных в хозяйстве вещей, которые идут из коробки (миграции, редис, кэш с множеством провайдеров, работа с очередями, консольная тулза artisan для разнообразных обслуживающих вещей). Изкоробочная работающая сборка вьюх в лейаут, минимум возни с авторизацией. Скоупы в ORM. Кусочки конфигов в файлах, которые удобно ставить в .gitignore. В общем, масса такого вот, мелкого, но очень удобного.

На Laravel ОДНОВРЕМЕННО можно уйти в глубины аццкого хадкора по Фаулеру, с тестированием всего и вся, с интерфейсами, депенденси инжекшнами, репозиториями, обсерверами, ентитями, гексагональными сценариями итд, итп, _подставить_любимый_паттерн_, И в то же время забить на это всё, сгенерить _ide_helper для подсказок по "фасадам" в IDE и фигачить код со статическими вызовами, как будто весь фреймворк написан на статике, как Кохана. Т.е. и сайт-знакомому-за-вечер и огроменный кровавый энтерпрайз делаются на одном фреймворке - в зависимости от того, насколько глубоко исполнитель хочет погружаться в свой продукт. Подобная гибкость - это, имхо, очень круто.

И еще - как показала практика фреймворкостроительства, или ты двигаешься вместе с развитием php, либо ты делаешь "более лучшее, удобное и грамотное" решение и тихо загниваешь с своем междусобойчике за пару лет. Laravel двигается максимально близко к php - следование psr, composer-платформа в качестве базы, фрейморк ставится оттуда и пакеты расширения тоже имеют composer-формат. Что говорит о том, что у фреймворка есть все шансы прожить долгую и счастливую жизнь.

Храните в отдельном месте настройки по-умолчанию. Для пользователей храните в json/xml виде только отличающиеся от дефолтных настройки. Суммарные настройки пользователя получатся путем наложения отличающихся на настройки по-умолчанию. Таким образом при добавлении новой настройки изменится только один конфиг — общий, и тем не менее он будет доступен у пользователя. А при изменении пользователем такой настройки измененное значение запишется в его личный конфиг.