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
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.