terrier

Ну, видимо этот ваш загадочный питон-скриптик не учитывает все различия между mysql и psql, так что даже если вы исправите эту конкретную ошибку ( нужно убрать кавычки ), то вылезет куча других.
Я бы порекомендовал воспользоваться для конвертации дампа чем-нибудь из более проверенных инструментов

Миллион пользователей в сутки - это 11 запросов в секунду - копейки для postgresql на хоть сколько либо нормально настроенном железе, никакой Redis вам не нужен.
Окей, учитываем, что пользователи приходят неравномерно в течение дня плюс есть запросы на дублирующий insert, но в любом случае простой
INSERT ... ON CONFLICT DO NOTHING
вам абсолютно достаточно.

SELECT * FROM t1 LEFT JOIN t2 USING (<some_field>) WHERE t2.<some_field> IS NULL

( и то же для t2 )
JOIN должен выполняться заметно быстрее аналогичного по смыслу EXCEPT ( впрочем проверьте на реальных данных)

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

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

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

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

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

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

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

Вот так вот более читаемо

CREATE FUNCTION is_tags_equal(article1 text, article2 text)
RETURNS boolean AS
$$
SELECT NOT EXISTS 
	(
		(SELECT tag FROM articles_tags WHERE article = article1 
			EXCEPT 
		SELECT tag FROM articles_tags WHERE article = article2)
		UNION ALL
		(SELECT tag FROM articles_tags WHERE article = article2 
			EXCEPT 
		SELECT tag FROM articles_tags WHERE article = article1)
	)
$$
LANGUAGE sql;

SELECT article FROM articles WHERE is_tags_equal(article, 'ArticleName') AND article != 'ArticleName';

Recheck Cond: (user_id = 114)
Rows Removed by Index Recheck: 153189
Heap Blocks: exact=39222 lossy=26507

У вас делается повторная проверка этого самого условия и она действительно отфильтровывает значительное количество строк. Long story short - вам не хватает work_mem, повысьте.

Prepared statements

https://www.postgresql.org/docs/current/static/sql...