Slashdot Mirror
Oracle Effectively Doubles Licence Fees To Run Its Stuff in AWS (theregister.co.uk)
Oracle has changed the way it charges users to run its software in Amazon Web Services, effectively doubling the cost along the way. From a report: Big Red's previous licensing regime recognised that AWS's virtual CPUs were a single thread of a core that runs two threads. Each virtual CPU therefore counted as half a core. That's changed: Oracle's new cloud licensing policy says an AWS vCPU is now treated as a full core if hyperthreading is not enabled. A user hiring two AWS vCPUS therefore needs to pay full freight for both, effectively doubling the number of Oracle licences required to run Big Red inside AWS. And therefore doubling the cost as well. The new policy also says: "When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable." That table says Xeons cores count as half a licence. Making the Table inapplicable to the cloud again doubles the licence count required.
Fuck that. He wants an island to moor it to.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
But if you're already planning on rewriting your software to work "in the cloud", migrating to a different database engine is not that much additional work.
It's nowhere near enough work to make their closed ecosystem an effective deterrent.
Step 1: Do this.
SQLite isn't remotely competitive with Oracle. It's nowhere near in the same league as even PostgreSQL or MySQL.
SQLite is a toy database with a huge amount of limitations that's found a niche in "I need a RDBMS for something simple, and rarely used". Thus the use for desktops to store things like configuration and music databases. In such cases it works well.
If you're even thinking at all of multicore performance, SQLite is not the database for you. It's got absolutely dreadful concurrency and will die under anything resembling a serious load.
I think this is an excellent move for Oracle, and I enthusiastically applaud them. I think the company will experience significant revenue increases with this pricing change, and that's always a good thing. In fact, I encourage them to raise prices even more.
For all the naysayers, as I always say when someone complains about Windows, "if you don't like it, don't use it".
I can just see some exec racking their brain trying to figure out how to increase revenue finally had an epiphany: "Eureka! I got it! We'll just charge our customers twice as much!" to which everyone at the board meeting replied "Brilliant! You deserve a promotion!". Smiles and carefree laughter were gifted with abandon that day...
My eyes reflect the stars and a smile lights up my face.
"Big Red's previous licensing regime [PDF] recognised that AWS's virtual CPUs were a single thread of a core that runs two threads. Each virtual CPU therefore counted as half a core."
That's flat out wrong; the actual old licensing regime counted each AWS vCPU as a full CPU core even though it was actually hyperthread. The new licensing regime counts each AWS vCPU as one half a CPU core (unless hyperthreading is disabled for the instance). That change alone effectively cuts the cost of licensing on AWS in half:
Old: Oracle running a instance with 4 vCPU (4 hyperthreads on 2 CPU): licensed as 4 CPUs requiring 2 cores of licensing
New: Oracle running a instance with 4 vCPU (4 hyperthreads on 2 CPU): licensed as 2 CPUs requiring 2 cores of licensing
The other change with the "Oracle Processor Core Factor Table" effectively doubles the cost back to where you started anyways:
"The intel core factor is 0.5, so an 8 core physical box requires 4 cores of licensing. Now on the cloud, an 8 core VM (16 vCPUs on AWS or 8 vCPUs on Azure) requires 8 cores of licensing."
Not really. Those that know it can make it jump up, sing, dance, and pretty much do anything a a thousand times faster than the pretend databases.
It's fast while huge.
If you care about your transactional data, it can't be beat by any other on-premises RDBMS.
But the major reason is Oracle's customers are using web applications built to run on top of Oracle. They buy the web application and then purchase Oracle as the infrastructure.
The reason Oracle is trying to dissuade customers from hosting on AWS is that they're desperate to get those customers hosting on Oracle's own cloud solution. AWS has a slick Database Migration Solution.
$5 / month hosted VPS on linux = awesome!
Is there a technical reason for using Oracle over something else?
Frankly, no, except in some specialized instances. I'd wager that 99% of the supposedly "mission critical" things that currently run on Oracle could safely be run on other databases.
Microsoft SQL Server and PostgreSQL are capable alternatives, as are DB2 and MariaDB. Even much-maligned MySQL can be used for many (perhaps most) of the applications that are using Oracle right now. All of these databases scale into the 100s of millions of rows and most include the transactional reliability that used to be exclusive to Oracle.
Oracle used to be the only choice for serious database work, but those days are gone. Unless you're doing a Moon shot or international banking you can almost certainly use an alternative DB and get the same functionality, robustness, and security (or better, in some cases).
Just cruising through this digital world at 33 1/3 rpm...
Oracle: Trying to price ourselves out of business since...well...SINCE!
Chas - The one, the only.
THANK GOD!!!
It seems like this move could mean one of two things: either Team Oracle thinks that there is sufficient willingness to pay among users of their products, and they were previously leaving money on the table in AWS instances; or they fully expect this to seriously dent use of their products in AWS; but don't care because they have their own 'cloud' offerings and want everyone not running on premises to be buying cloud from them.
Any guesses as to which it is? Is this a "Larry's a jerkass; but he knows that most of us will suck it up and pay the extra" situation; or is this a straightforward move to make one of the more popular cloud options blatantly uneconomic for use with Oracle stuff, in order to improve the apparent value of Oracle's pet cloud?
Although I agree with your general assessment, and I think the grand parent was just joking... I want to clarify somethings about SQLite before your post misinforms some of the visitors to this site.
SQLite is the most deployed database in the world. Oracle has more of a niche use case than SQLite. The functionality footprint is extremely small. The installation library is smaller than many DB connection drivers! In short, it provides SQL syntax based access to a flat-file in RAM or HD. It is simple and neat; yet provides ACID compliance. Programming environments and languages do not provide SQLite connectivity; they incorporate the entire system as a library.
It is the storage & decision mechanism for many mobile applications. It is utilized in many embedded & SOC systems. Although the library itself is single threaded, it supports concurrent access. So you can actually write programs to be multithreaded/multiprocessed to scale with the number of cores/CPUs. I personally have written programs that trade CPU counts & RAM for execution time.
But anyway, the cross section of use cases for Oracle/Postgresql/MSSQL and SQLite are basically non-existent... maybe you see some overlap in Prototyping to Deployment. MySQL and SQLite do appear to have some minor overlap, but its small there too.
Those that know it can make it jump up, sing, dance, and pretty much do anything a a thousand times faster than the pretend databases.
Of course it can. That's why companies like Google and Facebook, with their modest but slowly growing database needs, have all moved from pretend databases to Oracle as they've scaled up.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
While I agree that SQLITE isn't nearly the performance or features of Oracle, it's amazing how many places using Oracle because the name and cost impress the execs on the golf course could actually do just fine with PostgreSQL or Mysql.
Is there a technical reason for using Oracle over something else?
Yep, the PHB thinks that paying for support means he will get faster resolution of his production problems so he's willing to pay the support fees.. Plus he has a couple of Oracle Gurus on staff or contract too...
Yea, I know that's not a "technical" reason per say, but it's THE normal reason.
It's like buying IBM hardware, nobody gets fired for buying stuff that usually works, but many get fired for saving money and buying junk that doesn't work.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
DBA here. I work with SQL Server, Oracle, and MySQL. Each has it's pros and cons. One thing that Oracle offers which the other vendors can't really match at this point is Oracle RAC. It's the only out-of-the-box N+1 shared-disk solution that somewhat works properly. SQL Server has tried to offer something comparable with AlwaysOn, and MySQL has MySQL Clusters*, but these really don't fit into the same roles.
I haven't worked enough with DB2, and nothing large scale with PostGres to comment on those. I do feel that RAC is less of a necessity nowadays anyway, and will continue to be so, since the hardware has improved so much that the SQL Server/MySQL solutions can handle pretty much anything. I also don't think RAC is a good fit for a cloud-based solution.
*owned by none-other than Oracle nowadays
If you post as Anonymous Coward, don't expect a reply.
Hmm. Oracle themselves can't do that, and trust me, I've fucking demanded it from them.
Meanwhile even where an Oracle database is performant, secure, scalable, usable and technically optimal.. it's still too fucking expensive.
When it takes me three times as long to write a system to use a different DBMS, and I need three times as much hardware to run it, and it's still cheaper than fucking Oracle licences, you know it's not the technology that's the issue.
But you don't buy technology just because of the technology. Not at enterprises that can afford a sizeable Oracle footprint.
When a shrinking company suddenly jacks up their prices, it usually means they are milking the short-term for all they can and don't expect to be around in the long term (at least not as a real company).
Big tech co's basically have 4 choices when they start slipping:
1. Innovate and keep up
2. Hold existing customers hostage and milk them dry before they finish migrating away
3. Sue other co's using sketchy patent claims, hoping for at least settlements
4. Wither until you are bought out by a holding co. that does nothing useful
(Not necessarily mutually exclusive.)
Table-ized A.I.
Depending on the size of the database and the actual crunching involved, you can quickly get to impossible on SQL Server since databases are still not distributed. There are also lots of exotic features on Oracle that require third party tools or extensive development to be done in SQL Server. Also jokes aside, it's very possible to have a SQL Server implementation that's still more $$$ than Oracle or DB2. It's also just much much more fragile than Oracle or DB2.
found the m$ shill.
Erm...
I would however never recommend a greenfield install of it at this point. 15 years ago? Easy decision. But now? No way. Old projects will be in MS or Oracle. Everything new *will* be in one of the free ones.
Aren't shills supposed to try to get you to buy their product? This one seems to be suggesting there's no purpose to it on anything but legacy projects.
That hasn't been my experience. After using Oracle for 15 years (and having consultants like Burleson tweak our database many times) we have moved to Postgresql. Our experience is that Postgres is as fast or faster than Oracle in every instance.
MongoDB grabbing lots of Oracle customers
Wait, what? Nice try. You almost had us.
Breakfast served all day!