Есть большой проект, который работает на оракле+делфи
Стоит задача перевода его на совершенно новый стек технологий (postgres + asp.net core web api + react)
Но при этом нет возможности полностью прекратить разработку старого проекта, заняться ХХ месяцев переписыванием этого добра а потом выпустить переписанный
Поэтому принято решение перевод делать постепенно, перевести один модуль на новые рельсы, но при этом все остальное оставить по старому. Однако структура модулей проекта сильносвязная, т.е нельзя просто избавится от набора таблиц в оракле и вести их в постгри, таблицы из покинувшего старую гавань модуля нужны в других модулях и наоборот. Поэтому данные надо как то поддерживать связанными между базами

Какие я вижу варианты:
схему таблиц oracle использовать непосредственно в postgre через foreign_tables с помощью oracle_fdw. При этом есть такие плюсы и минусы:
+ Данные правятся и выбираются сразу в оракловой базе, все типа как работает без излишних усилий
- Будет гемор с производительностью, на foreign_table не повесишь индекс, джойн больше двух таблиц согласно доке не будет пихаться как есть в оракл а будет разбиваться на несколько незасимых запросов, что потенциально будет приводить к катастрофическим проседаниям производительности.
- Структуру данных нельзя будет поменять так удобно в новом проекте

Пробовать сторонние утилиты для мерж репликации баз, типа SymmetricDS
+ Теоретически если настроить все правильно, данные можно брать только те которые нужно, в нужной структуре
- Настроить это дело еще тот ад, следить постоянно чтоб не упало и все такое

Не делать онлайн синхронизацию данных, воспользоваться со стороны постгри мат вьюхами на foreign_tables с рефрешем on demand (выглядит относительно несложно) в оракле писать скрипты по вытягиванию данных с постри через гетерогенный сервис
+ Выглядит не так жопошно в настройке как настраивание автоматической репликации
- Конфликты в данных, необходимость доработки старого проекта, обновление данных не на лету

Поделитесь опытом, может кто-то занимался подобным, как лучше поступить

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

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

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

авторне указаны важные детали:
- на сколько критично время задержки синхронизации данных
- какие фичи оракла используются, которых нет в чистом пг (автономные транзакции, джобы, очереди ...). как собираетесь их реализовать в пг?
- логика проекта в базе или в приложении?

1. Это сложный вопрос, есть данные меняющиеся в жизни довольно редко (типа справочников) и если они будут переливаться по требованию или периодически не страшно теоретически. Есть то что меняется постоянно. Гипотетически то что меняется постоянно можно обновлять не транзакционно а периодически с интервалами раз в час скажем, при этом придется как-то мучится с конфликтами редактирования...
2. Автономные транзакции, пакетные переменные. Еще широко используется фича с тем что код в пакетах выполняется под правами создателя, не успел еще прочитать как с этим дело внутри постгревых функций. Мест с автономными транзакциями относительно немного, пока не думал о них, пакетные переменные через set_config по идее можно реализовать.
3. Вся логика редактирования данных лежит в ораклах пакетах, запросы для выборки данных в приложении. Более того, в оракле еще и полностью реализована интеграция со сторонними рест сервисами других систем


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

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

1) Пишем процедуры переноса данных (без ХП) из Oracle в PostgreSQL (Обратно данные течь не должны!). Которые будут работать пока эксплуатируются обе системы.


Не особо понятно как же в новой системе данные то менять, если они обратно в старую не будут передаваться..

авторкак вариант сначала избавиться от сильной связности, а потом уже мигрировать


Да, этот вариант тоже обсуждается, типа разбить архитектуру на ряд отдельных слабозвязных кусочков, и переводить по кусочку, но мне кажется это довольно напряжной затеей, которая в любом случае требует привлечения всяких BA и прочих чертей)