> At that point, they are probably looking (the very least) substantial per-core fees for the esoteric Oracle Enterprise features that they are using in production.
Nope, this is Oracle with their "you can only virtualise on our virt stack, or you have to pay for the whole farm if a single vCPU is on" trick. Except their licensing model is even more absurd than that - if you have cores switched off at the BIOS, they still count for licensing in Oracle land.
The substance of the article is quite correct: Oracle is using customer-hostile tactics to pump their numbers, so investors don't realise how badly their non-core activities are actually doing.
They do that with their own stack too (or at least they did). To avoid costs, you have to set up the VM such that it is locked to certain cores, and then that avoids the virtualisation portion of the license issues.
Oracle's always had very flexible, very hard to understand licensing. I know I never understood it. Pricing per-core,per-feature? Ugh. Then they make it really easy to add new features without knowing how much it costs. Double Ugh. We had a developer add a feature that cost us $100k/core just to process some XML. We quickly replaced it. We had a customer drop their Oracle license fees by 90% by locking their Oracle processes to specific cores (from 20 cores to 2).
Personally, I've never liked Oracle. Whenever I interact with them, it hasn't been fun (and I worked for them for a couple of years).
Although, Oracle's Cloud Licensing doc is clear about the requirements saying that every vcore is a core. [1]
> They do that with their own stack too (or at least they did).
Nope. If you buy Oracle's virt stacks (either RHEV-with-the-serial-numbers-filed-off-and-using-XEN or Solaris), they happily let you sub-capacity license. It's been that way for at least four or five years now.
> To avoid costs, you have to set up the VM such that it is locked to certain cores, and then that avoids the virtualisation portion of the license issues.
Under current licensing, that's a no, unless it's running in an Oracle branded VM, or zVM. No pinning or soft partitioning are recognised otherwise.
Have you ever tried to buy a server with only a single core for licensing reasons? It's impossible with modern hardware, the best we were able to do was a double core/single CPU system to run some oracle bits to talk to other oracle stuff. This server processed around half a dozen tiny xml files a day and buying a dedicated physical server saved a few hundred thousand over any other option we could figure out.
Your advice is spot-on, but you have to remember that many times the software being ran was written by someone who has long since moved on. Even if the source code is readily available, no one may be around to handle to porting it to another RDBMS.
Admittedly, this is where much maligned dependency injection frameworks can be useful. I have "upgraded" a large number of old Java software packages by simply placing a newer version of the library's jar on the classpath.
Ok, let's take a hypothetical (though, VERY close to what I've seen).
You're a SAAS company. Not a startup, a medium-size company that's been around for 20+ years. Your core software is close to 15 years old. It's 2.5 million lines of code (not that hard to do with "enterprise" software).
You have somewhere around 75 TB of data in probably 500 individual customer databases (multi-tenancy was not thought of in 2002 when your core software was developed).
This software expects Oracle to be the backend.
You can either:
1. Sink time and money into engineering time to evaluate, choose, and implement a new DBMS, and pay for consultants, licenses (if you choose a proprietary one), hardware (you'll need some, because you'll have that weird in-between time as you're migrating your customers' data).
You'll have to properly train your DBA's and developers (and ops people) on the new DBMS ($$).
You then have to write proper ETL scripts, schedule downtime with your customers (who have nearly 24/7 operations and transactions), make the switch, hope everything went well, then repeat that for your other 499 customers.
- or -
2. You can continue to pay Oracle, because you've got that in your budget every year, and it's not worth the hassle.
Oracle is a very good database indeed. You give it data, it gives it back utterly reliably and very fast. You send it crappy queries, it optimises the hell out of them. It's clunky and laborious to program and administer, but it works superlatively.
The problem is literally everything else about dealing with Oracle in any manner.
There used to be no real alternative. Fortunately, almost everyone with Oracle doesn't need something that ridiculously powerful, and Postgres is in fact the 99% solution.
> You give it data, it gives it back utterly reliably and very fast.
Well, it does... if you massage your data correctly, cause Oracle does not support many formats, and if it does not return some cryptic error for a condition that you'd never expect to exist in a DBMS.
Because if you use it for what it's for, Oracle is very, very good. 10 years ahead of the competition, easily and remember there is no "cheap" or "expensive" in business, only worth the money, or not.
But if you are just some schmuck developer who needs "a database" and you settle on Oracle and don't use all of its clever features because you've hidden it behind SQLAlchemy or Hibernate in an attempt to be database-agnostic, well then you're going to get taken to the cleaners, but it's your own fault.
Yes, Oracle's database is really very, very good, and if you know how to use it it's really powerful. I really did like working with it, but hope I never will again due to the company that sells it.
While Oracle is powerful (and fast and scalable and feature-rich), if you get to know another enterprise RDBMS in depth you'll find that once you start leveraging vendor-specific features you'll get more power as well (perhaps not as much as Oracle, but still quite a lot), at the expense of vendor lock-in.
Using an ORM or other abstraction layer to be DB agnostic for some businesses would be a better financial choice, since once Oracle's burned you, you can burn your bridges and walk away to something that might be technically less powerful, but will probably save you a lot of money. Vendor lock-in has its own costs. It depends on your scale and your plans to scale. Running large scale enterprise apps Postgres might be very risky (Postgres is getting better, though), but DB2 or another alternative might work as well and give you some leverage when the Oracle audit thugs come in to extort more money from you.
While I know I am biased, I sincerely believe that Oracle the company is a money grubbing monstrosity that acts effectively as an extortionist to their customers (they aren't alone here, but stand out to the degree they push the envelope of greed, they're a good 10 years ahead of the competition). They ruined Sun/Solaris, they ruined MySQL (letting it wither when it could be much further along by now), they are doing very dubious things with Java, they hosed OpenOffice, and I need to stop at PeopleSoft because my blood pressure is raising - and are pretty much trying to be the MS of the 90s in the markets they are in, and being in a position to be able to walk away from a business like that is a very practical business decision.
My belief is if you can feasibly write your app with an ORM then you should just use Postgres. If you can't, because you need $feature that the ORM doesn't manage, then buy the most powerful database you can afford and actively look for opportunities to exploit every bit of the functionality that you've paid for. The truth is being database agnostic is wildly overrated; in practice any organization will go through 10 languages before they decide to change their database, and no-one in their right mind cares about designing an app that is "language agnostic". You wouldn't start out in a language that supports, I dunno, closures, then deliberately not use them just in case you wanted to switch to another language in a couple of years.
That's a good point, and I mostly agree with it, but it's less true now than it was in the past. There's plenty of shops that switch around data stores for part of all of their data now. It may not be all that common to go from one SQL variant to another, but there are plenty of cases of people moving from SQL to NoSQL (and back or vice-versa). Think BigTable, Dynamo and Cassandra.
That said, there's as little hope of being database agnostic in those situations as there is being language agnostic. Really, being SQL variant agnostic is like trying to make sure you stay away from language features that you can't rely on if you switch between a C/C++ implementation and JVM hosted implementation of the same language. It's relatively easy (in the context of what we are discussion in this conversation at least), and as such may be feasible to take advantage of the flexibility it gives you later.
Perhaps a better example would be avoiding multiple inheritance not because you think MI is a bad idea but just in case you wanted to switch from C++ to Java in the future and you might need to re-architect.
Maybe, but I think it might be more apt to say "just in case you wanted to switch from C++ to Java in the future and you would prefer not to to re-architect."
IMO I think this is mostly an enterprise (or a "we serve enterprises") sort of mindset, where they have existing, vetted systems, and being able to match those targets opens you up to more of the market. Is their code target C/C++ or the JVM? Is their target DB Oracle, DB2 or MSSQL. I can imagine having an app that could be deployed on both Oracle and MSSQL back-ends would greatly increase your markets due to ease of getting it vetted in some organizations, just as I can imagine not too far in the distant past having both JVM and C/C++ versions might have done the same (but I thing that's still inherently harder to do).
While I agree with your technical views, just calling out a few unfair statements about the companies mentioned:
1. Microsoft certainly was aggressive with their competition in the 90s (and still are), but they've never been hostile to their customers, at least nowhere as much as Oracle.
2. Java has progressed much faster under Oracle than it ever did under Sun, and most people will agree they're doing that right, at least. If by "questionable" you mean the copyright lawsuit, consider that a) so far they seem to be legally in the right, and b) it was Google that did the questionable thing by ripping Sun off in the first place.
I've used 'em all, extensively. DB2 on a mainframe is comparable to Oracle, but SQL Server's a long way behind - MS don't make hardware to run it, see.
I'm not a database person, but I wonder what makes Oracle databases so much superior to free alternatives like, say, Postgres, that companies put up with the enormous costs and hostile attitude.
Can somebody explain why it makes sense from a business perspective to use Oracle products?
1. Like SAP or Salesforce, they don't sell to sane IT guys, but to enterprise executives that are far away from ops and just let them deal with it.
2. Ass insurance. You pay enormous amounts of money for the knowledge there's a dependable fix to the database in X hours, should there be a problem.
3. Certifications and tutorials. How do you know a DBA is any good if you don't know about databases yourself?
4. Permissions. Oracle let's you shield the database like no other competitor can. If you need DBA's that can't look into the database or character-level permissions because you don't trust the people you work with, Oracle is an enterprises' wet dream.
> You pay enormous amounts of money for the knowledge there's a dependable fix to the database in X hours
That's a problem right there. If you're paying ludicrous or plaid amounts, say 7 or 8 figures, then X might be reasonable and you'll get a decent team to work with you and fix your issue.
However, if you're only paying enormous amounts, then X becomes "whenever they feel like it", and a fix specifically requested for you is out of the question. You have to wait for the next patch cycle and hope your bug is fixed in the next patch. Anybody you talk to will begin every sentence with "I'm sorry you're having this problem," and they will be offshore.
Source: my company used a shitty db which oracle bought to squash competition and drive you towards the Big O product. We paid only 6 figures for support and got nothing useful. Then they bought Sun, which we were also into, and the same thing happened to us.
I got downvoted in a previous thread about this but I've worked at quite a few Oracle shops now:
1. PostgreSQL and most open source software is unsupported in most countries. There are a few mom + pop shops (usually one or two guys) who will provide support but usually without SLAs, 24/7, escalation support, legal frameworks etc. Support is for me generally useless but managers love them and CTOs expect them.
2. For every 1 PostgreSQL DBA there are 20 Oracle ones.
3. The costs of your database is nothing compared to the cost of your employees (money) or the cost of your project failing (politically). So if your best PostgreSQL DBA quits and you can't find another one or can't get training from the vendor then you're in trouble.
None of this is specific to Oracle. It's open source versus "enterprise" software. The trend is towards using enterprise flavours of open source software e.g. Hadoop (Hortonworks/Cloudera), Cassandra (Datastax), MongoDB (MongoDB).
> For every 1 PostgreSQL DBA there are 20 Oracle ones.
And only one has any idea what he's doing.
It's the MSCE effect, where incompetent people flock to the platform where they most easily can get a a job, and a trusted certificate where you must only recall some answers is a great tool for them.
When we first began using Oracle DB extensively Postgres was not in a state where it could have handled our needs. Now we have existing systems that work on Oracle. It would be extremely expensive to change that -- both in money, and in risk, and in developer time. New apps are not being built on Oracle DB.
Can anyone name a startup (let alone a YC startup) running Oracle software? Why would anyone open themselves up to these kinds of issues in a greenfield deployment?
And, if not, how much longer can Oracle keep up their growth by selling only to established companies? (Yes, they can sell maintenance forever, but how about growth?)
Different story here, but being strongarmed into using IBM I can tell there are some advantages that under a certain light and told in certain ways omitting specific details do resonate well to higher ups.
It is also worth remembering that once a startup migrates past initial growth and becomes a solid "big company" (e.g. Uber, AirBnB, and others mentioned here) they will often have Oracle in a few odd spots in the org where there are specific apps that may be best-in-class for their specific purpose but are also tied to Oracle as the DBMS. If HR and Finance are orgs run by different people I would bet that both of the have an Oracle DB or two hidden in the back somewhere...
AirBnB is the exception that proves the rule. I had to watch 2 minutes into the video to find that AirBnB's 2 person email marketing team selected Responsys. Note that Oracle acquired Responsys in 2013, so I suspect AirBnB was already using them, and got offered a discount if they helped Oracle seem less dated by having a hot startup on their webpage.
But, I believe it is a SaaS offering, not licensed software.
Uber seems to be using Oracle Financials, presumably because the SaaS alternatives aren't yet ready for Uber's scale. So, that does seem to be an example of companies going with Oracle when they get big enough.
And he forgot MySQL. But the way the original question was asked it was strongly implied that it is about their payed, enterprise offers. Not the open source software they unwittingly bought. They do nice work of killing mysql though.
From my experience at a previous company (who Oracle acquired, ironically), even if you're not using any Oracle software at all, Oracle will still demand to audit you because "any company over a certain size has to be using an Oracle product". And of course, you can get out of it by purchasing a license for their product.
The cost of declining? Dancing with Oracle's lawyers for months or years. The company opted to allow Oracle in, and no Oracle software was to be found (this was pre-Sun acquisition, so they couldn't even attempt a claim at MySQL or Java).
How is this even legal? How can one just walk into any business and ask them to show your 'technical' books? Is there some legal backing/construct to allow a company to do this? Was there compensation for time and materials spent?
I worked for a company a few years ago that fell foul to this, I wasn't privy to the exact details, but it was explained to me that Oracle did an audit and found the company were using the database on more cores than licensed for or maybe something like the VMWare situation.
To "make good" the company were offered the option to buy two Exadata racks and support contract at a very high cost, which they took up, and meant I had to spend a good few months migrating all of our applications over to the new Exadata database.
We're discovering that literally everything is better with Postgres. Mostly because instead of a single expensive point of failure, every app gets its own clustered PG pair. Because we can, because we don't have to think about licensing ever again.
Just everything not having to play nicely with anything else makes a huge difference.
The other nice thing is that PG is administerable by clear-thinking (and understand relational databases) non-specialists who can read a manual. You don't actually need big-ticket support unless you do.
And, guess what? Our Oracle support was most keen to offer Postgres support, because they too can tell which way the wind is blowing.
WHAT WE DO: PG 9.3 out of Ubuntu 14.04 repos. Failover pair with a primary and standby. Primary streams write-ahead log records to standby as they’re generated. Some script gaffer-tape to watch for primary failure and fail over (I think we haven’t ever yet actually had to invoke this). Conversions done by hand with ora2pg then faff and twiddling and unit tests. Gotchas: malformed sql that Oracle accepts but PG chokes on. All cobbled together just following the docs, almost certainly better ways to do all this.
This is not just Oracle, but it is pretty common for software dinosaurs (Microsoft, SAP...). We migrated to Redhat since Microsoft was unable to tell us exact price. Managers would risk criminal offense, by using software with unclear licensing terms.
"threatening customers with big bills for software they’re using but haven’t paid for"
The _really_ key bit: "haven't paid for".
The customer is not in compliance with their software license. At that point, they are probably looking (the very least) substantial per-core fees for the esoteric Oracle Enterprise features that they are using in production.
I worked for a software firm that was selling telecommunications software to carriers. We charged per subscriber per year. If the carrier wasn't paid, we didn't get paid. However, the carrier didn't keep their license up to date with the number of subscribers they had. Anyways, up comes the support contract for renewal. They complain about slow performance, slow releases and high fault rates - aiming for a discount.
We, pull out their 3 month old press release showing record numbers of subscribers, exceeding their license by 50%. To the tune of ~$500k/yr.
Yeah, the contract got renewed, with no discounts. You see, they'd already received the discount.
Take Away: If you're going to use software with a license, make sure you're in compliance with that license.
If you use Oracle, make sure you have a scripted install and that you audit the feature set against the license. This script and feature set needs to be re-audited for every new release, since the pricing and built-in features will change. It is UP TO YOU, the deployer to ensure that you are in compliance with your license. Oracle has automated audit tools, and when it comes time to renew, they know what you are using.
If you use Open Source, make sure you keep it SEPARATE from your main code base and read the terms of the license you are using. BSD (with advertising) vs GPL vs LGPL vs AGPL have very different impacts on your code.
oracle gave them the software on a quasi-good-will and the client had no means to prove where they used or not used the software. The article calls it "a tricky to not pay oracle" which is idiotic and should read "lack of due diligence".
i'm not defending oracle. i think everyone who signs with them deserve all that. but in contract law, they are pretty mundane, for that one case. Their IP lawsuits are another history.
Actually, no they're not. Oracle has a per-core license for Enterprise. Even on their own hardware (my knowledge is a couple of years old, so it may have changed), you either had to license the entire machine or link the database to a subset of the cores.
We ran into just this situation where we had large combined nodes with a database tier and an application tier running in different LDOMs (Solaris VM-equivalents) on the same hardware. Limiting the database server to just the cores it needed dropped the license costs insanely.
If a job is able to float around a cluster, the entire cluster would need to be licensed. As the article says, VMWare has a document stating exactly this.
From VMWare:
"Scenario B: Partially Licensed Clusters
When a customer does not have enough Oracle application instances to justify creating a dedicated cluster for those
applications, only a subset of the hosts in the cluster are licensed for the Oracle application. In this situation, the
customer must be careful to restrict the movement of Oracle application instances and virtual machines to only those
hosts that are licensed to run the product."
tl;dr: typical case of customer losing the tab on bar and complaining about paying the fee for lost-tab.
company A signed with Oracle on a contract that says they will pay per user and per server.
oracle asks them how many servers are running oracle software, company A has no logs, oracle says for them to pay for a big number of servers based on how many servers company A has available or pay a fixed "cloud" price.
company A now thinks they are too smart despite having made the asinine decision of supporting such contract in the past and goes to the press.
"typical case of customer losing the tab on bar and complaining about paying the fee for lost-tab."
It's more the customer getting a bar tab for a huge number of drinks they could potentially have ordered but claim they didn't while the barkeep doesn't keep track but just assumes the maximum number theoretically conceivable. Oracle's approach of letting customers hang themselves then putting their feet to the fire to prove they didn't use their software the way Oracle fantasizes is seriously ruthless (though this in no way exhausts their approaches to ruthlessly piling fees on customers - I'll never deal with them ever again).
My company recently had an Oracle audit, and yeah, the big concern was that the audits basically tend to find some non-compliance "but you'll be totally covered if you buy N cloud-services from us".
Why anyone uses Oracle is a god damn mystery to me. Why we use Oracle even more so - we have no use nor need for it's featureset.
you just described the agreement between you and the bar for when you lose the bar tab. (in those places where the customer holds the paper tab instead of leaving the credit card at the bar, that is)
Nope, this is Oracle with their "you can only virtualise on our virt stack, or you have to pay for the whole farm if a single vCPU is on" trick. Except their licensing model is even more absurd than that - if you have cores switched off at the BIOS, they still count for licensing in Oracle land.
The substance of the article is quite correct: Oracle is using customer-hostile tactics to pump their numbers, so investors don't realise how badly their non-core activities are actually doing.