[peterangular]

Same - it's such a difficult technology to deal with when outstanding flavors of DB exist (many for free): Postgres, MySQL, MSSQL.

The Oracle projects I've worked on are just people choosing it because "it's the safe business decision and a household name". I've had semi-good luck convincing folks over to MSSQL in these circumstances which is a night-and-day improvement in ergonomics/features.

[user5994461]

I thought MSSQL could only come with windows servers (until last year).

What is your experience with moving folks from Oracle / Linux to MSSQL / Windows?

I too think MSSQL is the best contender to replace Oracle in many regards, but I don't see the change in operations going well, different skillset and sysadmins.

[peterangular]

I mean - it's a nightmare and it hurts a lot. My experience is always lots of planning, refactoring the original schema, and working with SWEs directly on the code. As a SWE myself, the two major Oracle to MSSQL transitions have been heavily application-specific vs. other situations that may have a large number of downstream dependencies... I guess what I'm saying is my blast-radius was limited to 2-3 services vs. some of the nightmares I know other folks deal with here.

Given that my blast-radius was small, I was capable of doing a "from the ground up" approach by building data migration code by hand (ie: manually ripping through records, often validating them, doing any transformations, and writing them to the new DB target)... the largest DB I had to move like this was <100 tables and only 15Gb - I mention this because what I'm discussing isn't actually that impressive vs. your typical Oracle migration looks like!!! I was also incredibly lucky that the jobs I accepted were only had 2-3 years worth of data in there. People reading this are like "ha - easy mode" and they're 100% right.

Now that all this being said - I know my techniques are not ideal, and it's only one way to skin the cat... which is to replace the cat outright in an incredibly tedious manual technique. But hey, I still came in on-time and under-budget twice! I also had incredible confidence in the new DB target (MSSQL) as I literally touched/vetted everything by-hand. Stupid like a FOX!

Now if you can't do a hard cutover - all of this doesn't really apply. If I would have had to make a gradual transition I would leave it to someone better suited for the task.

> but I don't see the change in operations going well, different skillset and sysadmins

Oracle can be incredibly expensive or incredibly cheap... In my situation it was small-to-medium sized companies doing simple logistics stuff. It was incredibly cost-effective to replace it with an easier-to-use DB and most were happy to invite the change + learn new tooling.

It also was a HUGE productivity boost to the devs... I don't think people realize just how dumb Oracle/Oracle products are when it comes to simply "building something". To the extent that I find Oracle's product offering to be truly offensive, as-in it offends me as an engineer that someone would think to hand me such a non-ideal tool in 2020 ugh.

[takeda]

EnterpriseDB seems like PostgreSQL version that can emulate most Oracle's features, although I would personally use it as a step in migrating (i.e. move from Oracle to EDB, then gradually convert your data to be PostgreSQL only, once done move to pure PostgreSQL)

[boshomi]

With EDB ships a full featured PostgreSQL with some additional useful time-savers and a lot of experience for a fair amount of money. A part of this money goes direct into PostgreSQL development. So it's a fair deal.

[takeda]

That's a good point, also comes with support and is still much cheaper than Oracle.