Hacker News new | ask | show | jobs
by bdcravens 2030 days ago
As someone who has been fighting with a SQL Server to Postgresql conversion this sounds AMAZING. Too bad it won't be available before my conversion is complete (and if it is, that's an even sadder proposition)
2 comments

How are you doing your migration right now? Rewriting code by hand?
We got very far using DMS (Data Migration Service) and SCT (Schema Conversion Tool), especially once we put in some smart renaming conventions. It does like to make varchars everything it doesn't type-convert automatically. We also had to explicitly rename objects, mostly indexes - it like to truncate names, often overwriting previous entries when it truncates the name. Beyond that, there's some procedures and application code to rewrite (it's a Rails app built atop an older database that didn't follow standard Rails conventions) but I'd say automation and semi-automation (ie smart find-and-replace) got us 80% of the way.
Out of curiosity: besides cost, are there other significant reasons that drive your desire to switch?
Don't discount the cost, which is borderline astronomical; if you're on Enterprise, you're paying tens of thousands a year. For large installation, potentially six figures. And that's on-prem which is the cheapest way to do it more often than not.

A 2-core Enterprise license is nearly $14,000.

I guess it's linked to cost but the pure painfulness of just having licensing in the way of your infrastructure management is pretty annoying.

We literally have had this problem the last few months where we had a spike in load causing wide spread performance issues and the obvious answer was to give the server more cores but "we're not licensed for that" ... so everybody just suffered through it because temporarily giving the DB more cores for a few hours was just too painful / costly from a licensing point of view.

I came from Oracle, not SQL Server, but the largest benefit to me, is at a previous job, I ran Oracle Standard (that cost About $25k for our 2 core servers) and one of the critical limitations is you can't build an index without locking the table. The ability to do it 'online' was an enterprise only feature (that would have cost about $700k on our hardware), so we were unable to do any index changes on our tables, since it would take 10-12 hours to rebuild some key tables, and we couldn't block all our transactions for that long. SQL server also makes that an enterprise only feature.

PostgreSQL has the native ability to do that. There are lots of other benefits, but that is the first that comes to mind.

When they come out with Babelfish for Oracle, then stuff is going to get crazy. EnterpriseDB has some limits to its functionality, and its cost is pretty high.

liberatii.com has developed a similar tool like Babelfish for Oracle to SQL Server and PostgreSQL in case you're interested.
Plenty of reasons, but principally we want to bring our stack in line with the most common practices (ie, Rails/Postgresql) for simplicity's sake; this is crucial for our small team.
Postgres is functional by default, no need to throw asinine "with (nolock)" hints on every join.