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