Gradually migrate from SQL Server to PostgreSQL -
company has numerous applications running on sql server. database bit of mess.
the goal gradually move sql server postgresql (another sql server instance not option)
an ideal scenario if new applications connect postgresql, create new table structure, still able use/interact data legacy sql server (an app connecting 2 database servers not option).
foreign data wrappers not seem option, since technology immature , in case of postgresql, foreign tables read-only.
another wild idea connect sql server instance postgresql, new applications connect sql server, use postgresql's foreign database. foreign database ( guess ) have access host's database objects. , @ 1 point developers switch new apps sql server postgresql.
and of course there possibility try , sync data.
which best option?
everything suggest recipe pain , failed migrations. people rant , rave how awful, slow , unreliable postgresql if try use approach. it'd great political move wanted keep sql server, not way migrate postgresql.
there's read/write foreign data wrapper coming newer pg versions, it'll support other postgresql servers. supporting ms sql lot harder due need translate sqlstates , error messages, search conditions, , more, wrapper no doubt quite limited , have less great performance. say, fdw support immature @ point anyway.
there many things lose trying hybrid this:
no foreign key integrity enforcement
data types on each side might not behave 100% same data ok on 1 side , not on other. think timestamps/dates.
efficient joins require extremely sophisticated foreign data wrapper - what'll happen whole table fetched joined against locally. performance terrible.
writing queries becomes nightmare when you're doing trivial task. function names differ, etc.
you lose or weaken many acid properties and/or must use 2 phase commit, sucks performance.
seriously, don't this.
syncing dbs worse - unless it's 1 way, it's going recipe lost updates, deleted rows reappearing, , worse. two-way sync extremely hard.
start preparing apps move making them able run on both servers, 1 @ time. once you've got app ready run on pg, start doing load testing , reliability testing migrated copy of live data. then think migrating, have plans how reverse move if find last minute problems force delay.
if you're adding entirely new parts app might reasonable have them in pg if don't interact other data in db @ all. that's pretty unlikely, though, , sysadmins still hate when tell them need atomic snapshot across 2 separate databases...
Comments
Post a Comment