A few years ago, my then-employer (a smallish company, < 150 employees) had to deal with an Oracle compliance audit. I was shocked at the time to learn that there are companies (like Palisade Compliance mentioned in this article) that specialize in Oracle license compliance. We made it through just fine (in fact I believe we managed to get a small refund!), but having been through that (though not in any way directly involved), my take is that no one should ever do business with Oracle if they can possibly avoid it.
These kinds of things are everywhere. To pick one at random, if you want to list a product on amazon.com, there's no shortage of consulting companies that will figure out how to make it happen. And then you can get a consultant for your amazon advertising (the ads that go on amazon.com to advertise other products also on amazon.com) and a consultant to help make your company the default choice when a customer clicks the buy button in the "buy box," and a few more. You can easily spend hundreds of thousands on these consultants.
Honestly, the Amazon hustle is a crazy and fascinating little ecosystem in a bunch of ways.
Spreetail, one of Nebraska’s biggest tech startups, specializes in this area. Not only for Amazon, but other marketplaces like Walmart, eBay, TikTok, etc.
I have mentally trained myself that every time I read the word "Oracle", I replace it with "Larry Ellison needs a bigger yacht". Thus far, this has worked great for me in staying away from paying that organization even one dollar.
About 10 years ago, my then-employer had an Oracle audit and they were found to owe over $500,000 in licensing fees (the initial cost was much higher but they negotiated it down). They were blatantly violating their agreement by owning a single socket license and using Oracle on a half dozen large production servers and a bunch of dev servers. The DBA that ran the licensing script said "You know we're not in compliance right?" and the company execs said "No worries, we'll negotiate a good deal".
When I started, I asked about licensing while setting up a new production server and the CTO admitted they were under licensed and were planning to true up licenses next quarter, but over a year went by and they never did. I suggested that they work on porting to Postgres or MySQL/MariaDB and get off Oracle (or at least consolidate into fewer servers to reduce the socket count), but they never had the time to do that.
The company went out of business shortly after the bill from Oracle came due (not sure if Oracle ever got any money). I'd already left by then since I saw the writing on the wall -- as soon as they stopped providing snacks in the break room and the coffee switched from Peets to Folgers, I knew they were running out of money.
I once worked for a vendor company that sold a workstation: a computer with Linux and full-fledged Oracle server with the appropriate license and a small application written in PL/SQL.
When I suggested rewriting everything in Python, the CEO explained that on the client side, this solution was bought by MBA graduates who only knew Oracle, and everything else would be suspicious to them.
As a result, clients bought a cheaper solution from competitors - Windows and a small application written in C++.
"a specialist advisory company helping clients deal with Oracle licenses"
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.
Once you're using an Oracle database, you are probably using proprietary Oracle features, SQL syntax, client libraries, etc. The first chance you get might be a while. I once worked on a project porting an app from Oracle to another commercial DB. When Oracle is deeply embedded in your applications, it's easier said than done.
I would think that the way to do this would be to set up realtime replication from the origin oracle DB to a db with the same schema running on something much more 'normal' such as mariadb, and then set up client applications and libraries and queries to the newly replicated db in a read only mode. And then setting up test client application/libraries for write mode to a copy of the replicated db and verify everything is also working normally.
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.
Didn't say it would be easy - and indeed I'm well aware that Oracle is very different than MySQL. It's a painful transition process that more organizations will find necessary as the costs and hassle of oracle increase. If the end state goal is to have zero oracle in production use, people will have to figure out some kind of transition process to migrate away incrementally.
> I would think that the way to do this would be to
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.
Many legacy apps use tons of them. In the late 90's there was a style of application development where all DB access went through stored procedures. I find PL/SQL to be terrible.
There are still tons of PL/SQL developers, and a huge ecosystem that uses these things. Triggers were big at one time too.
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.
PL/SQL is terrible. But organizing your Oracle database in a way where you can do everything with only application-accessible statements is even worse.
Oracle places still do a lot of stored procedures.
That's why I wrote "naively". I know it's more complicated than I made it sound. It's the same with companies using mainframes, after a while you are so deeply invested (both financially and technically) that migrating might be more expensive than just feeding the corporate machine.
Still, depending on a vendor that treats their customers as rudely as Oracle does must be really annoying.
This is a great way to tell everyone you've never had to do this type of migration.
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.
Yeah I mean, I get it. Amazon spent years getting off of oracle. I'm just saying the only reason to be on oracle now is because migration is expensive. It says a lot that it's not a competitive product for new applications, and is in fact a liability.
Amazon provide multiple database offerings in their cloud, it was still a multiple year effort to move off Oracle:
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.
Oh man, in theory SQL is standard - in practice, you’ll need to rewrite (or do major surgery) on nearly everything that interacts with your Oracle instance. Unless you’ve been incredibly careful, which is unlikely.
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.
If you were using SQL so generically that you could easily substitute another database, you never should have been using Oracle to begin with.
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."
oracle products aren't really products you can ditch in most cases. generally what it takes to get rid of them is to go out of business and be replaced by a business that isn't an oracle customer. i had a very interesting thread about that dynamic on here with pamar three weeks ago, which will be very interesting reading for anyone who is wondering why people don't ditch oracle https://news.ycombinator.com/item?id=39397513
A smaller company I worked for a few years ago was migrating its old ERP legacy system and brought in some people from Oracle, SAP and Epicor. They decided to go with SAP, but I remember my boss in several lunch meetings saying that they didn't get a sales pitch from the other vendors as much as a litany of horror stories about why they shouldn't go with Oracle.
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.
How does anyone in IT management not know that Oracle is poison?
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"?
postgres dates from 01974, it used to be called ingres, so it has 50 years of engineering, not 30. the 'post' is from when they added 'object-oriented' features to make it 'post-relational'
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
That’s why it’s so important that competition is possible in a market. Such that legacy players with inefficient legacy technologies can be driven out of the market.
Oracle was a really solid choice 30 years ago, when 1Tb was an unheard-of database size. Back then, its query optimizer and a couple of strategic hints could make a huge difference in the runtime so that a report could be produced in minutes instead of hours.
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.
i agree that oracle was a solid choice 30 years ago, though they were already notorious for taking advantage of their customers
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
postgres is adequately efficient technology from last millennium, but at the level of execution efficiency it's pretty much the same as oracle, maybe a bit worse
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?'
Disregarding your list of "modern technologies" for a second, I think we agree on the core point here: Postgres may or may not be better than oracle DB. The sizeable advantage it has: you're not dependent on another company that will try to extract your margin as a fee.
I think the missing piece from that exchange is the reality that a lot of surviving, legacy, mission critical applications is that they are generally internal to large companies and have grown over decades to encapsulate business processes for entire industries. Consider an application that has been under active development for 30-40 years by 10-100 developers. The cost to rewrite is staggering, and the risk of failure is huge.
It started in the early 2010-s. First, relational databases were discouraged for new projects, then some projects started migrating from RDBMS to DynamoDB (or to the special internal NoSQL storage systems). The final push to move off Oracle (and RDBMS in general) started around 2016.
Got an email from oracle recently that said (paraphrased):
"We saw downloads for virtual box from your IP address but no licenses for your organization. Please let us know when is a suitable time to meet to explain the benefits of being licensed correctly."
Going through this at my employer and it's not VirtualBox they are inquiring about. VirtualBox is open source but the VirtualBox Extensions pack that gives useful features (usb passthrough, pxe booting, VM encryption, etc) isn't open source and Oracle changed the licensing around it sometime around 2018 to require payment.
Man that's terrifying. Every business with software engineers needs make sure that the the Oracle, MySQL, Java.com, and Virtual Box domains are blocked on their network.
They have actually been scraping ARIN IP space registration data for this and sending threats to people who hold IP space that has absolutely nothing to do with the actual business end user with a DIA circuit and static /30 that downloaded virtualbox. It's a ridiculous abuse of ARIN WHOIS data.
From the point of view of ISPs receiving such threats it is the most preposterous thing ever.
At my job, we have been merrily replacing Oracle products by open-source ones. You know, the common thing any employee feels morally obligated to do as soon as they realize there is an Oracle product in the stack. But the interesting bit is how those products got there: in some companies, you call it "modern stack" if the tech is less than fifteen years old. Sometimes they will replace a part of it and instead of jumping all the way to the present, they go like "Well, it's 2024 now. So, we need to migrate our stack from 2009 to 2010 this year. What version of Jboss came out in 2010? We need to update to that one. PostgreSQL? No, PostgreSQL 8 doesn't support deferrable unique constraints, which we need. We need to keep paying for OracleDB until June."
Not Oracle related, but ... in the late 90s, I was at a company that was doing web stuff - number of cgi/perl projects, but they'd started doing ASP as well in 98. Had a couple clients really scale up - one client had 80 servers load balanced, all running Windows NT. A friendly MS rep stopped by because the client had been getting so much press for their ecommerce work (which we were doing) and went... "oh wow, you have 150 servers that each should be licensed at $8k/server... let's talk!". The very next day the CEO came to a big dev meeting and started ranting that we needed to optimize the hell out of the sites to get the server count down ASAP. And... we also became an 'official' MS partner, which seemed to put the kibosh (officially or otherwise) on more expansive work in to Java. We were doing a bit of Java, but I think we'd have expanded more in that direction without the MS pressure. Yes, they fed us more work... but it meant... we were doing more hands on work (fixing loads of bugs in their commerce server) while they just collected license revenue. Great business if you can get it, I guess...
FWIW, I have no doubt that story was not isolated at the start of the web boom. I just happened to see inside a company when it was happening. It's also why I tend to take a FOSS-first attitude to tech.
Windows NT (just like Oracle) simply had a setting in the control panel for the number of connections allowed. You were supposed to buy licenses for all of them, but in practice nobody seriously followed that. Until they got audited by the BSA (Business Software Alliance).
To be fair, though, Microsoft typically was willing to work with companies and negotiate volume discounts. They were not interested in immediate shakedowns (like Oracle), but preferred building long-term relationships.
I guess this is why Microsoft is respected, while Oracle is despised.
Why would anyone have chosen Oracle in the last... 10 years (let alone even further back)? It's expensive, and many things I read from customers hints at deep regret.
Used to work there due to acquihire (throwaway acct since regular can out me).
Engineers were walked through how to interact with clients; don’t say this or that because of laws and treaties. But also to listen for customer language that suggests a customer is cheating Oracle; let Oracle know and they will send the lawyers.
Many many years ago I was working on making a phone OS (no not that one, this was for VoIP handsets, no not Cisco's) where we built an app suite on a Java VM. We wanted to use a Sun VM, I forget the acronym, that was bigger than J2ME but smaller than SE for which Sun, as far as we could tell, had no actual customers. You'd think they would be happy to have customer interest, but we got a total horseshit runaround on pricing. We could not base a product on something for which we had no idea of pricing. We used an open source Java which turned out to be adequate, but only just - no JIT, for example.
I only stayed long enough to migrate the service to Oracle infrastructure. Looks like they still offer it but when I left work was underway to roadmap decoupling what was then a OOP heavy Java monolith. I want to say primarily to move the UI/UX to Oracles internal standards and tech stack for such, but this was 2015; uuuuh I forget man.
My anecdote was based on interactions with sales, product, and senior engineering professionals. Internal culture seemed very forward thinking; work from home/anywhere Oracle had a business presence. Solid benefits, new parent leave, yoga/that kind of thing stipends. Though that may have been due to contractual obligation of the aquihire, and applied to my team only at that time. :shrug: The “problems” I saw were very much “first world problems”
And if they can’t say that (ie when it’s not true), they will intimate that you might be out of compliance, and hope you’re worried enough to just pay more anyway.
> Earlier last year, it made changes to the Oracle Java SE subscription model, basing it on a per-employee metric many said would increase costs for users.
I recently helped a factory change their timecard system because of this. They wanted a license for every employee and contractor who is capable of using any computer. Not just for the timepunch devices. Not just for the employees who use the timepunch devices.
I wasn't involved in the decision but it's my understanding that they did not even try to engage their vendor. They got legal threats from Oracle and put in a different solution on the same day. If you develop for java make sure your install process doesnt have something like "step 1: install java" cuz guess what they're going to download.
By paid support, you mean free steak dinners for middle management?
After dealing with Azul people, give me Oracle. Instead of seeing Azul people shuffling a bunch of charts around and making up shit on the fly to make it sound like their garbage product performs better than OpenJDK (it didn't for us. we benchmarked it. but shame on us, because I guess the steak dinners kept rolling in).
Look at this website, do you think it belongs to a legitimate company? https://www.azul.com/
The "new contract" vs old sounds like internal problems where I work.
We'll have a contract signed and everything is OK for a couple years. Then someone goes ham on inventing an approval matrix and other policy/rules to keep the offshored workers from making mistakes, and we have problems. Vendors getting paid late because of policy.
Even if we provide the contract we'll get arguments that it can't be so because it says something different in their database. It's that way in their DB, because if unknown, they default to whatever is best for our company.
My first thought was that you'd want to have ongoing diligence to be compliant. (Just like you don't want to have a delinquent debt with a loan shark who relishes penalties.)
But my second thought was that, if the audits are infrequent, some companies might intentionally violate the licenses. Or not want to know nor have a paper trail if there are inadvertent violations. (Both companies and individuals tend to like to kick problems down the road. Due to short-term thinking by businesses, and individuals who might be gone before chickens come home to roost.)
I worked at a phone company circa 2010 that basically had an office of Oracle compliance. They had lots of ongoing disputed. I sat in a cubicle across from the guy who worked to get projects off Weblogic Server after Oracle acquired BEA. The doctrine was that WLS cost more and used 4X the CPU and memory that alternatives did, in addition to avoiding Oracle audits.
Having gone through an IRS audit (spoiler alert: I do not recommend.), I can't imagine anyone willingly signing any sort of contract with a private company that allows them to treat you the same way.
> "We decided that we had a minimal amount [of Java]. We came up with a non-Oracle based architecture for development and we implemented a policy that pointed towards the other development platform and we evaluated methods to discourage or prevent the download of Java software,"
Look, if you are already in business with Oracle then you have my condolences. But if you aren't in business with them then there is absolutely no world where you should ever under any circumstances consider getting into business with them.
Nothing their database does can't be done with a different database. Even paying for a proprietary database can be done with a different party than Oracle. Do not, I repeat, do not do business with Oracle under any circumstances.
If you are already an Oracle customer and you have the opportunity to drop them from your stack. Do not hesitate, Do not pause, Immediately take that opportunity. There is no downside only upside in not doing business with Oracle.
Many large companies want a Batphone to call someone for support. They think that the vendor will magically just make things work. Normally that’s not the case. They might get it to work faster than your people, but probably not much quicker.
FOSS often has a Batphone, but few people pay for it. As a result management doesn’t want their Ops to be the only possible team to correct things.
Absolutely. I’m surprised that the belief in much of the comments is that the technical input of developers (like myself) affects whether Oracle gets consideration.
Oracle gets consideration because teams want to have a lifeline if something goes wrong or (worst case) someone else to pin the blame on when it does. And this happens because some businesses are actually so big that that level of comfort doesn’t even dent the budget.
Oracle actually has some nice parts and some rough edges (a statement that applies equally to PG and SQL Server too, for instance), but it comes with a king-sized security blanket.
What is weird is that there are many good technical reasons to use Oracle. It's a very advanced and impressive database. The risks from doing business with Oracle are nearly all legal and business cost related. The sort of thing that are squarely under the supposed expertise of the non developer folks.
My objections against Oracle are not technical in nature. It is almost entirely cost and legal risk related.
You can get a Batphone without doing business with Oracle. Microsoft SQL Server will give you a Batphone and would still be better than doing business with Oracle.
I don't know if it is still the case but MS SQL was very deficient tech wise against Oracle DB, and never really a contender for a large OLTP DB. To the point that for some applications, it simply would not work due to excessive locking.
support contracts are mitigations to management career problems, not to technology problems. Managers always want that throat to choke to deflect blame or buy time
I honestly don't know. I don't know how they stay in business since every developer I've ever met had a bordering on irrational hatred of them.
The only people I've met who like them were all Oracle consultants of some sort and not what I would call developers. When I've been forced to use an Oracle database it was because the company had a contract with Oracle and didn't want to allow any other database to be used. The decision was always several levels above my paygrade. I no longer accept positions at the kind of place that will do business with Oracle. It tends to signal that leadership of that place has some serious problems and too much money to realize they have those problems.
> I don't know how they stay in business since every developer I've ever met had a bordering on irrational hatred of them.
I'm sure you know the answer. Oracle doesn't sell to developers. They sell to the management of non-tech companies whose upper echelons are staffed by people with expertise whatever they do, which might be selling dresses or making plastic pipes. For what it's with SAP uses exactly the same technique.
Years ago when I invoiced Google they asked me to enter the invoice into their portal. (Generally, transcribing a vendors invoice into your accounting systems is something you pay your own employees to do of course, but big companies know how to apply the screws.) I remember that web form. It proudly said is was created by a summer of code student. It was ugly, it was concise, it was straightforward, and it just worked first go. Then Google moved to SAP, and used SAP's Aruba service to do the same thing. Aruba is layer upon layer of poor design, outages and bugs. Now, if a Google employee sends you an purchase they often offer to "get it into the system" for you. The reason is Aruba is almost unusable, so it they need whatever service is being offered badly enough they shepherd it through.
I can only guess, but my explanation is assume SAP sold the system to Google's accounting department. Somehow, SAP's sales found a way to bypass the ocean of expertise inside one of the greatest software engineering companies on the planet and sell the system to a pocket of people who had no idea about what they were buying. Colour me impressed with SAP sales.
I never worked for Oracle or as an Oracle consultant, but used to develop on Oracle RDBMS. I liked it quite a lot and it was very powerful. But today, I'd use Postgres.
My father worked on a multi year project to replace their darling (but very old mainframe system) with SAP. Apparently it's just awful and basically everything required a custom and tons of SAP consultants. By the time you're done, you had to reimplement the entire system on top of SAP with a ton of workarounds. That was his experience anyway.
Yeah, well MySQL or Oracle aren't the only database choices you have. And those two aren't even a choice between Oracle and something else. Both are Oracle the company properties now. Unless you meant MariaDB or something.
Yes, my mistake, I miss-read MS SQL as MySQL. MS SQL, being derived from Sybase, fully supports transactions. I'm not a fan of the price, but it's good.
We all know about Resume-Driven Development and hopping to another company every 18 months, incidentally avoiding the consequences.
But a very different model is when people are entrenched in a shop where not only is there big legacy investment/lock-in that would be hard/prohibitive for the company to shed, but also the personnel's familiarity with the legacy setup gives job security. So there are multiple reasons to pay the Oracle Tax (and/or Microsoft Tax) and not disrupt the status quo.
For Oracle DB there are a number of viable, well built and active open source alternatives like Postgres, is there any real alternative to Active Directory? I've long considered AD to be microsoft's true killer app, especially for very large enterprises.
Depends if you're masochist enough to run Samba. It can deal with the lower stack side pretty well, but the administration UI options available all pale in comparison to native Microsoft.
In any case many are shifting towards not running AD any more and instead use JAMF and similar solutions. Less attack risk (because let's face it, it's really really easy to shoot yourself into the foot with AD), and more buzzwords for the buzzword-happy C suite.
