Story: Oracle's core problem

• 
• 

"why not license per GHz, or by amount of storage attached?"

Yes, the old per CPU model doesn't work for multi-core, but don't forget that Oracle did try the per GHz route (remember the "universal power unit "). That flew like a brick in a glass house. But, pricing based on the amount of storage is equally foolish (very large databases (VLDB), data wherehouses (DW), and GIS sites be damned).

The real question to ask (and what to base a price on), is how much work is accomplished? To this date most software licenses (including Oracle’s current ones) are based on peak load (or in many cases) best guess of what may be needed. Most of that license cost is wasted in lost CPU cycles (you can’t bottle them for later).

Many laugh at Sun's "$1 per CPU per hour" scheme, but with the logging Oracle 10g does on what is actually happening in the database, that is a much more reasonable way to charge for a product. You charge by what get accomplished, not by what could be accomplished. Of course most software houses want to get paid up-front, not in the rears (on demand). This will need to change to make this work, and I see no other option as we move forward with the grid architectures Oracle itself is pushing (every five words).

Now defining that CPU has been the tricky part, but for Oracle it’s cake. Instead of GHz or MIPS or any other meaningless benchmarks of speed, base it on X number of IO’s per hour. Maybe just charge a low entry fee (basic support with people you can understand (hint) and updates), and then just charge for work (insert / update / delete) IO’s. That gets those VLDB’s. DW’s, and GIS sites into the clear – and helps encourage efficient SQL coding at the same time.

Example: One single core CPU working for one hour (60 minutes) at 100% doing X work I/O’s = $1. Ten 2 core CPUs working for (60/20) 3 minutes = $1. You choose how fast you need the results, and decide when to upgrade (or use “grid”) hardware. The customer wins - and everyone is treated fairly.

• 
• 

• 
• 
• 

Full Talkback thread