MySQL stripped naked by Oracle

A (slightly) technical perspective on the MySQL-M&A war between Oracle and SUN

The first thing to understand is that database systems are not directly connected to the underlying storage infrastructure. There are many reasons for that but the most important are speed (e.g. cache management) and transactional capabilities (i.e. management of concurrent accesses). This layer that interfaces in between the Database and the Storage is called a Storage Engine and also sometimes a Table Engine or (1) Table handler.

MySQL historical storage engine is MyISAM (1) ISAM came first but was quickly replaced by MyISAM and because of it, MySQL had both the great quality to be extremely fast in reading data and the blatant drawback of not allowing transactions (unlike say PostGreSQL). This wasn’t a big  hurtle at first since simple web applications needed speed and scalability before anything else; but as web applications grew more sophisticated, it became a major hindrance and prevented MySQL to penetrate  new markets.

MySQL people realized this  and decided to remediate  the situation. As an alternative/complement, they would offer the commercial product InnoDB to their Enterprise customers (remember, MySQL is dual licensed) and offer the Open Source community to use (1) either InnoDB (dual-licensed GPL except for the hot-backup module which is fully proprietary) or BDB (Berkeley DB)   (1) which never had much adoption. In the meantime, MySQL  would work on Falcon, the transactional  replacement for MyISAM.

But in the past 3 years, the landscape had started to change. Oracle acquired SleepyCat (who was  dual licensing –and as such controlling- BDB) then   acquired Innobase the maker of the commercial InnoDB (1)-and as such controlling InnoDB GPL- MySQL was starting to look like a giant with feet of clay (MySQL dropped BDB immediately after Oracle purchased of SleepyCat (1) as per Oracle request).

I’d venture to say that it was a way for Oracle to lock MySQL into accepting to get acquired or at least to give second thoughts to any other potential acquirer of MySQL. The beauty of the maneuver is that it cost peanuts  to Oracle: $3M for InnoDB, probably around $100M for SleepyCat (it was never disclosed officially). Also of interest is that InnoDB was custom modified by Google to run zillions of MySQL instances.

Now, without any decent “Storage Engine” (the new Falcon does anything but soaring in benchmarks (1)although some say that Falcon is not that bad), it’s going to be difficult for MySQL to keep both commercial and community momentum. (1) And as of today MySQL works in parallel on yet another competing storage engine candidate Maria . 

Enters IBM that  recently purchased  SolidTech (the maker of SolidDB), a company much involved instorage engine (1) and grid computing (storage clusters and cloud computing need this kind of technology to distribute large databases).

As explained by Matt Asay, IBM  released SolidDB as open source.  SolidDB, which is GPLed on SourceForge/collabNet, seemed indeed to be a good ((1) actually poor ) candidate for a storage engine that would allow MySQL to replace InnoDB or to wait for Falcon releases to improve. (1) In the meantime MySQL customer base depends on Oracle's goodwill to renew the contract between Innobase/Oracle an MySQL/SUN. 

 

No doubt SUN engineers have the ability to do something. After all, SUN is a software company, right?

 

(1) update 04/21/08:  corrections or additions brought to MTG by well-informed, reliable sources.

Comments

[Taylor]

I think you're a little late, Sun has bought MySQL. You say "or at least to give second thoughts to any other potential acquirer of MySQL." but that didn't happen.

Right now Oracle is making money with InnoDB, it's not in their best interest to cut off that revenue stream. If they cut it off all that happens is Falcon gets all the attention, catches up, and Oracle is out a revenue stream. Oracle being evil and killing MySQL only works if InnoDB is totally irreplaceable, it may be difficult to replace but that's not the same thing.

[L505]

"This wasn’t a big hurtle at first since simple web applications needed speed and scalability before anything else; but as web applications grew more sophisticated, it became a major hindrance and prevented MySQL to penetrate new markets."

This is a contradicting statement. Scalability is all about growing more sophisticated.

You might want to read dbdebunk.com and check if you make the "quote of the month" in the future.

[jm]

"Scalability is all about growing more sophisticated."

Actually, it's not. Scalability is for a system to have the ability to manage with much more inputs (e.g. data, people) without substantial modification (e.g. typically just by adding hardware)

[Mike]

There are other options you might want to consider. One on the near horizon is ScaleDB. They deliver on two very critical advances: (1) They use a cluster-ready shared-everything architecture like Oracle RAC and IBM's mainframe databases (IMS and DB2)it supports transactions, etc.; (2) They introduce an indexing engine that not only stores column values (like B-tree), but also column relationships. This means it goes directly to the data queried...NO JOINs. This makes it extremely fast and scalable. If you would like me to put you in touch with them, let me know.