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