Станислав Макаров

Нет, гарантии нет. Менять привычный 5432 порт у сообщества причин нет. Теоретически поменять дефолтный порт можем, это не так сложно технически - но зачем? Мы не гарантируем совместимость с последующими версиями и вполне можем решить что-нибудь сломать нужное, если сообщество согласится что оно того стоит. Гарантий не дадим, но вполне можно рассчитывать что будет 5432 ещё очень долго использоваться по умолчанию, нет причин его менять и есть веские причины его не менять.

Ну и стоит упомянуть, что дефолтный порт может быть указан в конфигах, параметром запуска, и в том числе на этапе компиляции базы:

--with-pgport=PORTNUM set default port number [5432]

Пока он как-то сам выбирает порт

PostgreSQL не занимается таким. Просто откажется стартовать если не удастся открыть сокет. Номер порта не менялся очень давно, если менялся вообще хоть когда-нибудь от самого основания ещё post-ingres в 198х годах.

Вот сторонние скрипты - те могут иметь какую-нибудь такую логику. Например, пакеты debian/ubuntu при вызове pg_createcluster попробует прописать в конфиге ближайший свободный порт начиная с 5432. Никакой зависимости от версии СУБД нет. Нужен новый кластер? Ок, возьмём ближайший свободный порт и настроим на использование его.

Советую обратить внимание на курсы, которые я указал ниже.
Обучение
• Джош Кауфман «Первые 20 часов. Как научиться чему угодно... быстро»
• ru.learnlayout.com
• htmlacademy.ru/program
• w3schools.com
• flexbox.ninja
• Карта развития веб-разработчика

Видеокурсы HTMLAcademy
• htmlacademy «Базовый HTML и CSS»
coursehunters.net/course/bazovyy-html-i-css-18-2017
• htmlacademy «Продвинутый HTML и CSS»
coursehunters.net/course/prodvinutyy-html-i-css-po...
• htmlacademy «Профессиональный HTML и CSS Уровень 1»
coursehunters.net/course/professionalnyy-html-i-cs...
• htmlacademy «Профессиональный HTML и CSS Уровень 2»
coursehunters.net/course/professionalnyy-html-i-cs...

Справочники
• htmlbook.ru
• webref.ru
• developer.mozilla.org/ru/

Выполнение заданий
• flukeout.github.io (изучение селекторов в CSS)
• flexboxfroggy.com/#ru (изучение flexbox в CSS)
• flexboxdefense.com (изучение flexbox в CSS)
• dmitrylavrik.ru/training/process/flexbox-grid (создание сетки на flexbox)
• cssgridgarden.com/#ru (изучение gridbox в CSS)

Задачи для практики:
• htmlbook.ru/practical

Макеты для практики:
• drive.google.com/drive/u/0/folders/0B8LYygUI_oGeSG...
• freebiesbug.com/psd-freebies/website-template/
• symu.co/freebies/templates-4/
• dcrazed.net/free-photoshop-psd-website-templates/

Их возможно оформить в виде npm модулей? Если да, читайте документацию npm install он умеет ставить с гит репозитория. Ещё вариант - git submodules, но там большой шанс нарваться на танцы с бубном.

cpp файл

template <typename T>
Tree<T>::Tree()
{
}

Как по-твоему компилятор во время компиляции этого cpp файла узнает, что ты захочешь работать с Tree<int> в каком-то другом файле?
Только если ты в этой же единице трансляции сделаешь явное инстанцирование нужных тебе типов. Иначе объектный файл, получившийся в результате копиляции этого cpp файла будет (почти) пустым.

Если переношу реализацию конструктора и деструктора в заголовок - все работает.

...и это -- типовое решение этой проблемы.

Конечно вам нужно нанять бэкенд-разработчика, а фронт сделать своими силами в виде заглушек (т.е. максимально упрощенно, без дизайна, адаптива и т.д.) Когда логика будет готова, нанимаете фронтендера и он делает красиво и удобно. Сами подумайте, какой смысл делать обертку для несуществующего приложения? Мало ли что там и как будет в итоге.

WebSQL, увы, стал deprecated еще до того как вышел из черновика. Браузеры тут же кинулись встраивать SQLite, а Oracle испугался и через Mozilla продавил, что браузерное хранилище должно быть key-value. Кое-где (скажем откровенно, в Chromium-based браузерах) до сих пор работает, но когда отвалится -- неизвестно.
У IndexedDB есть одно ярковыраженное преимущество перед localStorage: по умолчанию доступное место заметно больше. Остальное по вкусу, тем более что есть фасадные надстройки над всеми тремя типа localForage.

Если необходимо хранить статичные данные для браузерного расширения

Если это пользовательские настройки, то альтернатив chrome.storage нету. Если это данные необходимые для работу самому расширению (скажем, карты уровней для игры), то проще и логичнее держать это в, например, JSON.

Qt

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

Ну и, разумеется, DBA (или заменяющий его обязанности человек) думает над тем, как именно вносить нужную миграцию в базу

Добрый день! Хотел посоветоваться с опытными бэкэнд программистами.
Встала задача создать высоконагруженный проект (Типо кассового решения). В базе данных через 1-2 года планируется , около 150млн записей у основной сущности (продажа).

150 миллионов записей - это ерунда, а не высоконагруженное решение.
У меня 5 000 записей в секунду создается на довольно дохлом (что-то около 500 рублей в месяц стоит хостинг) сервере VDS/VPS
Два года? 150 миллионов - это за ... 9 часов.
И да, я не считаю это решение высоконагруженным.
Нагруженным - да.

то есть нужно максимально быстрое чтение этих данных

Нет.
Людям не нужно снимать отчеты со всех данных сразу. Только часть данных интересует их.

Если всё же нужны все данные сразу (ну какая-то общая статистика) - то на основании первичных данных выполняется агрегация (например, по ночам) и тогда отчеты будут строится вообще - мгновенно.

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

Вот только если ваши 1000-5000 пользователей будут постоянно получать данные - только тогда это и можно назвать нагруженным решением.

Как лучше хранить такие данные? в одной таблице? или можно разделить по разным таблицам, и держать связку какой пользователь в какой базе хранит.

Это зависит от того что за данные.
Что именно за данные.

Сам пишу на mysql - потянет ли он такие объемы, на нормальном железе. Или нужно смотреть в сторону других БД?

MySQL довольно быстр.
Например, PostgreSQL более функционален. Но насчет скорости - не обязательно.

потянет ли он такие объемы, на нормальном железе

А в официальную документацию заглянуть?
https://dev.mysql.com/doc/refman/8.0/en/limits.html
150 млн. записей для современных СУБД и современных компьютеров (даже не на "нормальном железе") - это тьфу, а не нагрузка.

P.S.:
Для высоконагруженных систем формирования отчетов есть различные решения:

1. Предварительная (ночная) агрегация данных
   
2. Master-slave, где master только обновляет данные, а slave - только для отчетов.
   
3. Специализированные, заточенные под конкретный вид данных СУБД (InfluxDB, Redis-Tarantool-Aerospike, ClickHouse пр.)