I would (naively, I know) imagine that if you need to hire a third party to help you sort out your licenses with a vendor, you would do whatever it takes to get rid of that vendor. It's almost as if Oracle wants their customers to ditch them the first chance they get.
Oracle's got a lot of nasty things going for it, for sure. But there's a reason people still use it: part of it is vendor lock-in, of course; the other is that the database is actually really nice.
And chances are, you started using Oracle because of some enterprise software somewhere for which you don’t even have the source - so good luck.
And don’t forget, Oracle will encourage you to use all their Oracle specific stuff everywhere in their documentation. It’s a giant, idiosyncratic mess.
I guess you could call it "vendor lock-in" to use the more advanced SQL, analytic functions, and stored procedures or you could call it "getting what you paid for."
Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database
Today I would like to tell you about an internal database migration effort of this type that just wrapped up after several years of work.
After confirming everything is working okay, at some point in time, have a "rip off the band aid" moment of cutting off the oracle db and declaring the replicated one as the new primary.
I rewrote the dozens of PL/SQL SP into the retarded language that MySQL has.
It's not impossible in any way.
The devil as always Is in the details. The real problem comes With stored procedures. Maybe this is why I shy away from their used to this day. The last migration I did to Postgres wasn’t too bad; the app had only a few basic stored procedures.
Oracle places still do a lot of stored procedures.
You will be surprised how H1B 'specialised talent' developers are just people who have worked on these ancient technologies all life, are near impossible to replace so you are left with no options but to hire them.
Oracle is a whole different specialisation in itself and its tentacles go very deep and afar.
Hell, even benchmarking their DB goes against the license.
https://www.enterprisedb.com/docs/epas/latest/fundamentals/e...
All our business logic was into PL/SQL stored procedures, I migrated them to MySQL stored procedures.
The MySQL language is a bit retarded, and some extra work was needed, but everything was doable.
Now the code runs in both MariaDB and Aurora in AWS.
We only pay AWS for the servers now.
Still, depending on a vendor that treats their customers as rudely as Oracle does must be really annoying.
more recent systems like impala, spark, kafka, cassandra, leveldb, influxdb, rocksdb, duckdb, monetdb, lmdb, sqlite, parquet, hbase, etc., are a lot more efficient at execution efficiency, though in many cases that's only 'up to such-and-such a scale' or 'above such-and-such a scale' or 'for such-and-such use cases'. there's a perhaps too comprehensive overview of the scene at https://github.com/newTendermint/awesome-bigdata
but the big business inefficiency with oracle is not technical, it's the human problem of not having control over your core business processes or the ability to continue carrying them out if, when oracle says 'jump', you say anything but 'how high?'
These days? You can buy a server with 1Tb of RAM, for the price of one Oracle license. Any Open Source database will work just as well as Oracle on these kinds of datasets.
And if you have bigger datasets, then they are likely not that suitable for RDBMS anyway.
also postgres's query optimizer has gotten a lot better
i wouldn't say any open source database. it depends on your index. there are recondite but not unreasonable queries for which mariadb and sqlite still produce pathologically poor query plans which won't complete in a reasonable time even with all the data in ram. and a few years ago i had postgres totally fall over on important queries because we'd forgotten to add an index, and it took us days to figure it out because we were using amazon's outsourced postgres thing and didn't know how to admin it
SQLite might be a bit under-powered as well for these kinds of jobs.
It worked since my manager said he asked around and did his own research and wondered how they're even still in business since everybody he talked to said the same thing - whatever you do, do not go with Oracle.
That blows my mind. I encountered two Oracle audits within 7ish years in the industry, and heard about others. If anyone goes to MIS school, there should probably be a contracts day somewhere in that curriculum, and "don't use Oracle" should be the first bullet point.
Maybe in the 80s and 90s without the internet it might be more hush-hush. But this is now two decades of aggressive Oracle audits. Two decades is a LONG TIME for companies to get off of a vendor.
And now there's Postgres with, what, 30 years of engineering into it? Honestly if your database scale exceeds Postgres, you should be on Cassandra or other specialized database that will actually scale to really large sizes, not some weirdo hyper-hardware Oracle setup.
Virtually every large org has a very involved process for vendor selection. HOW DOES ORACLE SURVIVE THESE? How does any IT organization not have a standing policy of "generally don't use oracle unless you absolutely have to"?
as i understand it, oracle mostly sells to executives above it management, but there are also lots of executives in it management who aren't as concerned about the survival of their company as they are their own careers. it's hard to point to cases where company failure can be specifically pinned on oracle licensing fees, but since a company running on oracle can never switch away, ultimately there's no reason for oracle to leave any profits for the company shareholders when they could simply extract them in licensing fees. unless the company has pre-existing licensing contracts in place, i guess, and successfully defends them — which it won't be able to do if it fails oracle's licensing audit, and obviously copyright infringement is ubiquitous in every company, so most will fail, and then oracle can alter the deal
https://aws.amazon.com/solutions/case-studies/amazon-databas...
https://aws.amazon.com/blogs/aws/migration-complete-amazons-... https://news.ycombinator.com/item?id=21258127 (Edit: 2019)
They want the biggest, juiciest hits, not to have to fight with savvy buyers for what they believe they deserve.