Alles wat je voorstelt is een recept voor pijn en mislukte migraties. Mensen zullen razend en enthousiast zijn over hoe vreselijk, traag en onbetrouwbaar PostgreSQL is als je deze aanpak probeert te gebruiken. Het zou een geweldige politieke zet zijn van iemand die SQL Server wilde behouden, maar geen goede manier om naar PostgreSQL te migreren.
Er komt een read/write external data-wrapper voor nieuwere Pg-versies, maar deze zal in eerste instantie alleen andere PostgreSQL-servers ondersteunen. Het ondersteunen van MS SQL zou een stuk moeilijker zijn vanwege de noodzaak om sqlstates en foutmeldingen, zoekvoorwaarden en meer te vertalen, dus elke wrapper zou ongetwijfeld vrij beperkt zijn en minder dan geweldige prestaties leveren. Zoals je zegt, is de FDW-ondersteuning op dit moment sowieso te onvolwassen.
Er zijn gewoon zoveel dingen die je verliest door te proberen een hybride als deze te maken:
-
Geen handhaving van de integriteit van buitenlandse sleutels
-
Gegevenstypen aan elke kant gedragen zich mogelijk niet 100% hetzelfde, dus gegevens kunnen aan de ene kant in orde zijn en aan de andere kant niet. Denk aan tijdstempels/datums.
-
Efficiënte joins zouden een uiterst geavanceerde buitenlandse data-wrapper vereisen - dus wat meestal gebeurt, is dat de hele tabel wordt opgehaald en vervolgens lokaal wordt samengevoegd. De prestaties zullen verschrikkelijk zijn.
-
Het schrijven van query's wordt een nachtmerrie als je iets anders doet dan de meest triviale taak. Functienamen verschillen, enz.
-
Je verliest of verzwakt veel ACID-eigenschappen en/of moet twee-fasen commit gebruiken, wat slecht is voor de prestaties.
Serieus, doe dit niet.
Het synchroniseren van de DB's is waarschijnlijk nog erger - tenzij het een manier is, wordt het een recept voor verloren updates, verwijderde rijen die opnieuw verschijnen en erger. Tweerichtingssynchronisatie is extreem moeilijk.
Bereid uw apps voor op een verhuizing door ze op beide servers te laten draaien, maar slechts op één tegelijk. Zodra u de app gereed heeft om op Pg te draaien, kunt u beginnen met het uitvoeren van belastingtests en betrouwbaarheidstests met een gemigreerde kopie van de live gegevens. dan denk na over migratie, maar heb plannen om de verhuizing ongedaan te maken als u last-minute problemen tegenkomt die u dwingen uit te stellen.
Als u geheel nieuwe onderdelen aan de app toevoegt, kan het redelijk zijn om ze in Pg te hebben als ze helemaal geen interactie hebben met de andere gegevens in de DB. Dat is echter vrij onwaarschijnlijk, en je systeembeheerders zullen je nog steeds haten als je ze vertelt dat je nu een atomaire momentopname nodig hebt over twee afzonderlijke databases...