[Alupis]

Can someone elaborate on what specifically something like this would be used for?

I would imagine if you're going through the pain of migrating off Oracle, picking something like IvorySQL is just a half-measure. Why not just make the switch to PostgreSQL (or other) and be done with worrying about compatibility? How long will this project last, and how great will the compatibility actually be - is it a drop-in replacement?

Most folks use ORM's these days too - making switching databases simple (although not always trivial).

So why does this need to exist?

[kijin]

Full migration can take months if not years. Meanwhile, a drop-in replacement will allow you to stop paying Oracle immediately.

I wouldn't be too optimistic about ORM usage in the kinds of organizations that chose Oracle in the first place.

[SoftTalker]

If you're using an ORM then you're by default using the database fairly generically. I'd ask why you are paying for any commercial DB in that case.

Organizations who committed to and paid for Oracle are probably using a lot of the features that are unique to Oracle. Or they have a lot of legacy that is.

If IvorySQL can take all their custom plsql packages and ETL batch jobs and run them without changes that's a big win. It's not clear to me that it really can do that, though.

[dragonwriter]

> If IvorySQL can take all their custom plsql packages and ETL batch jobs and run them without changes that's a big win.

It's a big win even if it just substantially reduces the transition cost, though being completely drop-in would be even better.

[Alupis]

> It's not clear to me that it really can do that, though.

It would seem exceedingly foolhardy to put all your eggs into, what is essentially a compatibility shim layer/plugin, that may or may not actually be compatible with Oracle or all of Oracle.

The company behind it also is an unknown (to me at least) - HiGo[1].

So, IvorySQL is FOSS and free (as in beer) - but what happens if some feature doesn't actually work like advertised? Or something isn't implemented yet? Now you're paying HiGo for support instead of Oracle - although I'd trust Oracle's product a lot more personally.

> I'd ask why you are paying for any commercial DB in that case.

People pay for commercial DB's for a lot of reasons - including having someone to call at 3am when things go bad. Look at how prevalent SQL Server is - most of the deployments I've seen are because the company simply decided they will use SQL Server for everything (ie, not a technical reason).

[1] https://www.highgo.ca/

[marcosdumay]

If you want to use this, you will port your code, run your tests, fix an issue here or there as needed, and develop for Postgres for now on.

None of those steps is particularly risky. If any of the steps that may fail brings an insurmountable obstacle, you ditch the project and go back to where you started.

> People pay for commercial DB's for a lot of reasons - including having someone to call at 3am when things go bad.

Oh, the old support excuse for proprietary software. The Oracle support is excellent, but good hope getting anybody to help you at 3am. Good luck getting anybody to actually help you in less than 24 hours anyway. None of the big proprietary software distributors offer anything like this. Oracle is way ahead of the competition on that they will even actually help... kind like you get when you hire a local company to support Postgres for you.

[Alupis]

The scale of your operation and license subscriptions matters for the level of support you receive, naturally.

Big Microsoft shops, like state governments routinely have Microsoft staff fly out and work closely to bring new services online, etc. You cannot expect that level of service if you're just paying for a single database instance, of course.

IBM's support is also legendary - you will get a person on the phone at 3am, and even have a service technician onsite in the morning if needed. Personal experience with this one - they'll fly someone in from out of state to replace a hard drive if it means meeting their service levels.

[marcosdumay]

> you will get a person on the phone at 3am

And that person will do nothing else but waste your time.

What is the natural result of any interaction with Microsoft support too. Not limited to 3am calls.

Anyway, I wonder how RedHat has adapted to the IBM culture. I haven't dealt with software support for a while now, what I'm very grateful for.

[ngcc_hk]

Database engine might be the last product one can test and trust open source support wise. For individual it is fine. For company and your whole business is there … at least some paid support is important. It can’t be day to day stuff as you will know. It is some unusual combination which when encounter, you have to pass along your program, setting … can’t do it in open forum I suspect.

[Schnitz]

Oracle is expensive. Salesforce has been developing something similar internally for years to replace Oracle.

[jamesfinlayson]

So did Amazon/AWS I think.

[ergonaught]

The last time I did real work with Oracle and MSSQL, I must have created something like 50 megabytes of "SQL" via stored procedures and such for them. The idea of migrating away from those databases to something with compatible syntax and such would have actually been feasible, but otherwise 100% dead on arrival.

If you could "just switch" then you probably shouldn't be using RDBMS at all.

[u320]

Because migrating off Oracle to an Oracle-compatible DB is less work than migrating to straight Postgres. This is not rocket science.

[tomrod]

'' is NULL in Oracle. The switch is non-trivial.