Tudo o que você sugere é uma receita para dor e migrações com falha. As pessoas vão reclamar e elogiar o quão horrível, lento e não confiável o PostgreSQL é se você tentar usar essa abordagem. Seria uma grande jogada política de alguém que queria manter o SQL Server, mas não uma boa maneira de migrar para o PostgreSQL.

Há um wrapper de dados estrangeiros de leitura/gravação vindo para as versões mais recentes do Pg, mas inicialmente só suportará outros servidores PostgreSQL. O suporte ao MS SQL seria muito mais difícil devido à necessidade de traduzir sqlstates e mensagens de erro, condições de pesquisa e muito mais, portanto, qualquer wrapper sem dúvida seria bastante limitado e teria um desempenho inferior ao ótimo. Como você disse, o suporte ao FDW é muito imaturo neste momento.

Há tantas coisas que você perde tentando fazer um híbrido como este:

• 
  Nenhuma aplicação de integridade de chave estrangeira
  
• 
  Os tipos de dados em cada lado podem não se comportar 100% da mesma forma, de modo que os dados podem estar corretos de um lado e não do outro. Pense em timestamps/datas.
  
• 
  Junções eficientes exigiriam um wrapper de dados estrangeiros extremamente sofisticado - então, o que geralmente acontece é que toda a tabela será buscada e depois unida localmente. O desempenho será terrível.
  
• 
  Escrever consultas torna-se um pesadelo quando você está fazendo qualquer coisa, menos a tarefa mais trivial. Os nomes das funções diferem, etc.
  
• 
  Você perde ou enfraquece muitas propriedades ACID e/ou deve usar o commit de duas fases, o que é péssimo para o desempenho.
  

Sério, não faça isso.

Sincronizar os bancos de dados provavelmente é ainda pior - a menos que seja de uma maneira, será uma receita para atualizações perdidas, linhas excluídas reaparecendo e pior. A sincronização bidirecional é extremamente duro.

Comece a preparar seus aplicativos para uma mudança, tornando-os capazes de serem executados em ambos os servidores, mas apenas um de cada vez. Assim que você tiver o aplicativo pronto para ser executado no Pg, comece a fazer alguns testes de carga e testes de confiabilidade com uma cópia migrada dos dados ativos. então pense em migrar, mas tenha planos de como reverter a mudança caso encontre problemas de última hora que o obriguem a adiar.

Se você estiver adicionando partes totalmente novas ao aplicativo, pode ser razoável tê-las em Pg se elas não interagirem com os outros dados no banco de dados. No entanto, isso é bastante improvável, e seus administradores de sistema ainda o odiarão quando você disser a eles que agora precisa de um instantâneo atômico em dois bancos de dados separados...