Todo lo que sugieres es una receta para el dolor y las migraciones fallidas. La gente despotricará y delirará sobre lo horrible, lento y poco confiable que es PostgreSQL si intenta utilizar este enfoque. Sería un gran movimiento político por parte de alguien que quisiera mantener SQL Server, pero no es una buena forma de migrar a PostgreSQL.
Hay un contenedor de datos externos de lectura/escritura para las versiones más nuevas de Pg, pero inicialmente solo admitirá otros servidores PostgreSQL. Admitir MS SQL sería mucho más difícil debido a la necesidad de traducir sqlstates y mensajes de error, condiciones de búsqueda y más, por lo que cualquier envoltorio sin duda sería bastante limitado y tendría un rendimiento menos que excelente. Como dices, el soporte de FDW es demasiado inmaduro en este punto de todos modos.
Hay tantas cosas que se pierden al intentar hacer un híbrido como este:
-
Sin aplicación de integridad de clave externa
-
Es posible que los tipos de datos de cada lado no se comporten al 100 % de la misma manera, por lo que los datos podrían estar bien en un lado y no en el otro. Piense en marcas de tiempo/fechas.
-
Las uniones eficientes requerirían un envoltorio de datos externos extremadamente sofisticado, por lo que lo que sucederá generalmente es que se buscará toda la tabla y luego se unirá localmente. El rendimiento será terrible.
-
Escribir consultas se convierte en una pesadilla cuando estás haciendo cualquier cosa menos la tarea más trivial. Los nombres de las funciones difieren, etc.
-
Pierdes o debilitas muchas propiedades de ACID y/o debes usar la confirmación de dos fases, lo que apesta para el rendimiento.
En serio, no hagas esto.
La sincronización de las bases de datos probablemente sea aún peor:a menos que sea de una manera, será una receta para actualizaciones perdidas, filas eliminadas que reaparecen y cosas peores. La sincronización bidireccional es extremadamente duro.
Comience a preparar sus aplicaciones para una mudanza haciéndolas capaces de ejecutarse en ambos servidores, pero solo en uno a la vez. Una vez que tenga la aplicación lista para ejecutarse en Pg, comience a realizar algunas pruebas de carga y de confiabilidad con una copia migrada de los datos en vivo. entonces piense en migrar, pero tenga planes sobre cómo revertir la mudanza si encuentra problemas de última hora que lo obliguen a retrasar.
Si está agregando partes completamente nuevas a la aplicación, podría ser razonable tenerlas en Pg si no interactúan en absoluto con los otros datos en la base de datos. Sin embargo, eso es bastante improbable, y sus administradores de sistemas aún lo odiarán cuando les diga que ahora necesita una instantánea atómica en dos bases de datos separadas...
