terrier

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

Ну, смотрите - в чем проблема с ES в качестве primary database: он может периодически терять апдейты, плохо ведет себя со split-brain, нет ACID, бывает реплики ведут себя неразумно и т.д. ( какие-то баги фиксятся, какие-то добавляются)
Однако, возвращаясь к вашей задаче - у вас всего 2 терабайта данных и почти нет записи, только чтение. И, думается мне, у вас там не 40 машин в кластере, верно?:). То есть сценарий типа: "Мастер вырубился при сплит-брейне, 2 слейва провозгласили себя мастерами, пока чинили на них позаписывали по 5 терабайт противоречивой информации, мы все про***ли, где бэкапы" вам на самом деле не грозит.
Так что почему бы не хранить эти несчастные 2Тб в эластике + бэкап/снэпшот плюс еще где-нибудь для надежности против нашествия инопланетян ( у вас все равно данные почти иммутабельные).

Вы, похоже, не совсем понимаете, суть понятия "транзакция". Оно означает только то, что логическая группа операций либо выполнится полностью, либо полностью откатится. Что "увидят" соседние транзакции в процессе работы конкретной транзакции - зависит именно от уровня изоляции. Может быть примерно все, включая промежуточные итоги незакоммиченной транзакции, а может быть совсем ничего

Я так понимаю, вам хотелось бы, чтобы прямо и названия колонок и типы строго совпадали?
Портабельного способа сделать такое, насколько я понимаю, нет, так что проще всего
1). Получить названия колонок из обоих запросов. Сравнить.
2) Получить типы колонок из обоих запросов. Сравнить.
3). И вот уже после этого - EXCEPT.
Все это способом специфичным для вашей базы.
Если все совпадает - запросы идентичны.

Они ещё помнят, что мы рассматриваем третий кейс

Ключевое слово помнят - похоже, что вас беспокоит ( якобы имеющийся у вас ) недостаточный объем краткосрочной памяти.
В связи с памятью можно отметить несколько моментов:
- Сама по себе идея "что-то я недостаточно умный/что-то у меня плохая память" может быть некоторым неврозом. У него есть определенные психологические причины, но как "побеждать" его понятно - отдохнуть и подумать отстраненно о своей жизни
- Память достоверно связана с интеллектом, а вот то, что именно общую память можно существенно увеличить некими тренировками сейчас считается спорной идеей.
- Могу однако, поделиться собственным опытом "прокачки" краткосрочной памяти - я пробовал, то что мне казалось разумным: учить стихи, учить иностранные языки, шахматы, решать математические задачи "в уме" + спорт и хороший сон. Субъективное ощущение результата - я "насобачился" в уме варианты, какую-то картинку или дерево принятия решений довольно большого объема. Уверенно сказать, что я стал "умнее" или память улучшилась не могу. Однако, теперь я точно уверен, что бумажка и ручка - лучшие помощники в рассуждениях.

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

вызывает процедуру eq_statuses_techtracker(), которая может завершится с ошибкой

"Завершиться с ошибкой" в смысле бросить исключение? Тогда это откатит всю транзакцию ( если никто это исключение не ловит )

1) ЗП - больше - лучше;

Не особо определяется технологией. В данном случае - примерно одинаково

2) Широкая распространённость и низкая проекто-специфичность технологии

Java wins. У DBA все-таки ограниченная применимость.

3) Перспективы перехода на смежные развивающиеся технологии

И там и там вам никто не помешает перепрыгнуть на модные Scala или NewSQL - решения.

Настораживает, на самом деле название "Full stack junior Java developer" - фулл-стэк в данном контексте - это что - джава, джаваскрипт и кофе варить директору?
Вторая контора готова предложить кучу вариантов вчерашнему студенту - тоже не очень хороший знак.
Итого, посмотрите на условия в обеих компаниях ( не кидают ли по деньгам, какой офис и тэдэ) и идите туда, где интересней. Вам перейти на что-то другое будет еще совсем не поздно.

1). Ваш "SQL" больше похож на псевдокод
2). Эти запросы не эквивалентны ( почитайте внимательнее про LEFT JOIN )
3). Первый вариант быстрее ( при разумных допущениях ), второй - известный антипаттерн, применяемый начинающими программистами, которых напугали "медленными джойнами". На самом деле джойны - это именно то, что реляционные базы могут делать очень быстро и очень продвинуто.

Если вы переходите с MySQL на Postgres, то ничего особо сложного быть не должно - есть много автоматических конвертилок для миграции в этом случае. Сломается только то, что и так работать было не должно:)
В обратную сторону возможны сложности, все-таки у посгреса есть много фич, которые mysql не знакомы или пишутся по другому.

Настоящий линуксоид бы автоматизировал подергивание мышкой каждые 30 секунд.

Есть ли такие специальности, где существует физмат направление и слегка программирование

Ну, собственно, да - смотрите такие вузы как МФТИ и МИФИ, физика там в большинстве специальностей в большом количестве идет "по умолчанию", чуть-чуть некая "информатика" там идет, потому что это обязательный курс, и в некоторых факультетах подмешивается значительное количество CS.
Классические примеры - ФРТК МФТИ, который задумывался как кузница кадров для радиоэлектроники, но выпустил уже много компетентных программистов или, скажем, тот случай, когда топовая российская команда разработчиков СУБД PostgreSQL вышла с физфака МГУ.
Так что такое сочетание нередко ( как бы это ни показалось кому-либо грустным ).

мне либо сидеть и ждать этой чудесной вакансии

Почему сидеть и ждать? Написать weekend-проект на каждом из тех языков, которые нравятся, выложить на гитхаб и добавить в резюме. Резюме рассылаете всем, в нем указываете, мол пишу на python/go/php, коммерческого опыта нет, вот есть гитхаб. Уровень всем понятен будет. На первую работу берите, что дают, нужно будет немного освоиться в реалиях коммерческой разработки, а вот потом уже будете выбирать среди предложений.
Ну и да, я бы на вашем месте поднажал бы на PHP, а вот Go оставил бы до лучших времен, он модный, но нишевый.

и тут я вспомнил что у postgresql есть параметр wal_writer_delay = 200ms, что-же получается и у postgresql может быть такая ботва что клиент думает что строка сохранена а все накрылось до сброса журнала на диск???

По постгресу. Если включено synchronous_commit = on , то в любом случае перед тем как сообщить клиенту об успехе ждем записи в WAL на диск. Это дефолтные и почти всегда разумные настройки.
В случае synchronous_commit = off гарантируется только то, что база даже в случае падения ( метеорита ) останется в непротиворечивом состоянии, но WAL будет записан на диск через некоторое время, зависящее от настройки wal_writer_delay. Это режим "готов получить шанс потери данных при падении в обмен на увеличение производительности".