Migration from MSSQL to PostgreSQL?
Has anyone of you done this?
There are features that you pay mucho dollars for in MSSQL, which PostgreSQL appears to manage just fine.
Migration from MSSQL to PostgreSQL?
Published
I rant, therefore I am.
It’s not the migration process that I worry about, it’s the end result. Partitioned tables would be nice without the 200.000 NOK per year per MSSQL Enterprise license.
we’re using pg in conjunction with devart unidac, it can scale horizontally, vertically, no broblem (: there are a lot of features, most of which we don’t yet use, however, it’s nice to see the latest ones which include json support and more to come
I’d say: do it, and don’t look back, *nix servers are cheaper and pg runs on many platforms and it’s updated frequently, personally, I have pg installations from xp, to w7, debian and osx, all running without a hitch ^_^
Unix servers are unthinkable, to be honest – as we have tons of Windows specific code.
Our challenge is that we have tables which have millions of rows, and table partitioning (http://technet.microsoft.com/en-us/library/ms188730.aspx) would have been so nice to boost performance, but MS wants top dollars for that. PG is supposedly capable of that as well. We have a few .NET assemblies which would have to be rewritten for PG as well, but supposedly the T-SQL procs and functions are source code compatible?
you’ll have to test that and see how it goes, I think a few days can be invested to see if $ 30k/year can be saved or spent elsewhere (:
Michael Thuma – it is indeed management purposes, as we need to track food stuff for as long as it has a shelf life, and then a few months (due to need of traceability in case of quality issues). Combining it in a view is too costly and creates yet another set of monster indexes. That is exactly what partitioning fixes. The partitioned indexes can be searched in parallel by the engine, and the rarely changing old content ones are not included in the updates for the new and fresh.
Duplicating the structures in different is how we have done until now – but the maintenance cost of doing it that way is massive, due to code duplication.
The articles have lifespans that vary between days and years. Some articles need a maturity to be eligible for use (cheese). In addition, there are many other factors that govern if a pallet should be accessible or not. The challenge multiplies with the varieties – but key is to keep the applications and databases capable of dealing with everything in the same structures and configurable rule sets – or we would be sunk in code detail management.