Та ні, чому, цілком справедливе питання! :) Ми самі колись розмірковували над тим чому не timestampz, але інколи доводиться жити з тим що є. Моє припущення чому був зроблений такий вибір — це якщо оперуєш лише в UTC, то вибираєш між тим чи слідкувати за тим що пишеш UTC, чи за тим що повертаєш UTC. На практиці нам це не сильно заважає, ми раз на рівні сервіса визначаємо в якій часовій зоні пишемо час, і більше про це не думаємо.

Ми оперуємо виключно в UTC, тому з точки зору запису — так, слідкуємо аби завжди писати в UTC, але з точки зору читання використання without timezone дозволяє уникнути випадкової неявної конвертації в різні часові зони.

Технологію не пробували, але якщо говорити про дата-міграцію через копіювання + CDC, то DMS нам підходив як інструмент, у нас з ним є експертиза і все таке, але, по-перше, для цього потрібно було б виділяти інфра-інженера з іншої команди на довгий проміжок часу, по-друге, якщо під час міграції щось пішло б не так, то відкатити, пофіксити, і заново накатити було б суттєво важче (з RDS достатньо зклонувати таблицю і попередньо прогнати всю міграцію переконавшись що вона правильно накатується).

— Партиціонування немає, бо розмір таблиць поки що не створює проблем.
— Гарне питання! По-перше, updated_at — це поле типу TIMESTAMP WITHOUT TIMEZONE в яке ми самі пишемо час. По-друге, річ у тім що читання і видалення відбувається з використанням btree індекса tmp_idx, дані в якому відсортовані по двох ключах (updated_at, td_id), тобто доти доки ми паралельно не читаємо і видаляємо щось з індекса результат буде детерміністичний навіть якщо при читанні ми сортуємо лише по updated_at. Але що якщо з якоїсь причини це не так і результат не буде детерміністичним? Наприклад query planner вирішив не використовувати індекс. Зауваження слушне, але ми про це особливо не думали тому що 1. кількість таких випадків на нашу думку була б малою (на практиці ні під час тестів, ні під час міграції не помітили жодного), 2. якби таке трапилося ми б ідентифікували рядки які не оновилися і домігрували б їх.

Не певен що ви маєте на увазі, втім ми розглядали те що ви описуєте (розділ AWS DMS), це робочий варіант, але ми обрали інший підхід :)

Це не були проблеми пов’язані з тим *як* ми пишемо дані (ізоляція транзакцій чи реплікація даних). Тут радше був нюанс з тим як зберігалися деякі дані та до яких сутностей вони були прив’язані. Раніше існуючий підхід працював, але з розширенням функціоналу системи довелося внести зміни. На жаль, це все що я можу сказати :)

Відписав Дмитру нижче на схоже питання

Ця панель побудована через promql, зелена лінія — це irate, а жовта — це rate за 15хв

Можливо це не досить добре пояснив в статті, але ми оновлювали більш ніж одну колонку для кожної з таблиць, і майже для кожної з них причини відрізнялися одна від одної, деякі з проблем були семантичними і мова йшла про консистентність даних, а не про швидкий доступ. Були й інші причини, але в статті вирішив сфокусуватися на «як», радше ніж «чому» і прийняти за передумову що така міграція була доцільною. Тому згадав лише денормалізацію, як одну з причин, оскільки її доволі просто пояснити для людей поза контекстом.

Це обфусковані назви використані суто для прикладу, таких таблиць у нас немає :)