eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Oh, MySQL. We hardly knew ye.
Here you are, perched on the final release of 5.0. Its expected out within mere days; this, the version destined to get you playing with the database big boys, with transactions and stored procedures and all those enterprise must-haves.
Then all of a sudden, from out of the darkest pits of Mordor, Oracle comes and snatches the golden ring.
Yes, on Friday, the database behemoth gulped down InnoDB, the development company behind what some people consider to be one of the most crucial pieces of technology in the innovative 5.0 database release.
Sure, the InnoDB storage engine is only one of many storage engines that ships with the database.
But from what I hear, if you want to do transactions with MySQL, youve got to have InnoDB.
This is how Jeremy Zawodny, an open-source database expert and MySQL user who works at Yahoo, put it in a recent blog post: “Its the de-facto choice for developers who need high concurrency, row-level locking and transactions in MySQL.”
That take was echoed by a former Oracle database marketer: Paola Lubet, now vice president of marketing and business development at Solid Information Technology.
Lubet was with Oracle for seven years and was senior director of database product marketing.
“The recently announced new 5.0 features of MySQL are powered only by InnoDB, [which] now belongs to Oracle,” Lubet told me. “As a result, MySQL is left only with its Classic edition that is file-based and doesnt support transactions, triggers or store procedures or any other advanced database features.”
Who to Believe
Now Zack Urlocker, MySQLs vice president of marketing, told me thats not true, from a technical perspective.
“From a technical perspective, its the opposite situation,” he said. “Part of the reason we have this pluggable storage architecture is it allows you to have higher-level capabilities: the parser, the optimizer, caches, all of the SQL and all of the management services.
“Thats all completely independent of the storage engine. That means replication, metadata, stored procedures, triggers and views are written at a higher level and written independent of storage engines.”
Robin Schumacher, worldwide director of product management for MySQL, contacted me to explain why Lubets claim is “100 percent false.”
“All features in the upcoming MySQL 5.0 are not dependent on InnoDB at all,” he said.
He sent a document that runs through a simple test that “unplugs” InnoDB from the MySQL database server and then demonstrates the creation of three MySQL 5.0 flagship features: a stored procedure, a trigger and then a view.
“Moreover, the actual fact is that InnoDB loses a great deal when it is unplugged from MySQL,” Schumacher said.
“Once detached, InnoDB loses a lot of functionality including replication, robust stored procedures, triggers, views, all SQL functions, data encryption/decryption, actual authentication/privilege support, any GUI management tools interface, data load/unload, and much more,” he continued.
“Even more painful is that InnoDB loses a great deal of SQL parsing ability (their parser is only 7 percent the size of ours, indicating a great loss in ability to interpret SQL), and a real database optimizer.”
This is why Innobase came to MySQL in the first place, Schumacher said, and why many of MySQLs partners and customers write storage engines for MySQL: “They get so much functionality by simply plugging a storage engine into our server rather than writing a complete database from scratch,” he said.
So transaction support will still exist in MySQL, even without InnoDB through its BDB engine, which supports full commit/rollback functionality.
Finally, Schumacher said, customers should rest assured that MySQL will always provide bug fixes and enhancements to the server layer where any new features, like those in 5.0, may be used by any MySQL pluggable storage engine.
So you can take your pick of who to believe: On one side you have an ex-Oracle employee whos working with a company that competes with Oracle, plus an open-source expert and MySQL user of long standing.
On the other side, you have MySQL itself, which, of course, has got to put a sunny face on this. (Id give MySQL the benefit of the doubt when it comes to the importance of InnoDB to the heralded new features in 5.0, given Schumachers input.)
Hell, what else can they do? This rabid puppy of a deal came hurtling out of nowhere, dripping with foam. Its certainly not like Oracle called up MySQL to reassure them that things will be hunky-dory after the merger—until, that is, after the acquisition was a done deal.
“It [wasnt] a surprise in the sense that weve got a multiple storage engine architecture,” Urlocker said. “We knew we had a third-party relationship with InnoDB that may or may not last forever.”
Yes, but for Gods sake, why? Why have a contractual relationship with a company that makes such a core piece of your architecture? Why not just buy them, as the company has done with other important pieces?
“I cant comment on past, present or future acquisitions,” Urlocker told me. “All I can say is theyve been a good partner in the past and will be a good partner going forward, even as part of Oracle.”
OK.
But dont expect MySQL customers who want to take MySQL 5.0 commercial to be solaced by that, since by doing so they leave the cozy community of GPL and venture out into the icy darkness of having to enter a contract with Oracle, via MySQL, after the current InnoDB contract expires in the coming 18-21 months.
This is what Oracle says in its release: “InnoDBs contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship.”
This is what Lubet, former Oracle sales mistress, has to say about that: “Im pretty sure, as an ex-Oracle employee, that the sentence in the release about Well certainly be happy to renew the contract, that it was written by Larry and that he was laughing out loud as he [dictated it].”
As Lubet sees it, Oracle found a flaw in the MySQL business model. It cost virtually nothing for the company to exploit that flaw.
And at the end of the day, will Oracle work particularly hard to ensure it helps to keep alive an open-source database that could threaten to eat away at its meat and potatoes revenue stream—i.e., database licenses and support?
At any rate, MySQL has a contract with InnoDB thats in force for some time. That gives MySQL and its community time to plan. At this point, Urlocker told me, MySQL doesnt have any plans to fork the code, but its always an option, if Oracle does something thats perceived as a slap in face.
Lets hope that Oracle is up to good. Lets give the company the benefit of the doubt.
But just keep in mind, as Lubet pointed out, that Oracles responsible, above all, to its stockholders, not to a little open-source database vendor or its users.
Oh, and Oracle?
Wasnt in the mood to chat with me about it.
Lisa Vaas is Ziff Davis Internets news editor in charge of operations. She is also the editor of eWEEK.coms Database and Business Intelligence topic center. She has been with eWEEK and eWEEK.com since 1995, most recently covering enterprise applications; database technology; and RSS, syndication and blogging technologies. She can be reached at lisa_vaas@ziffdavis.com.
Editors Note: This story was updated to include input from Robin Schumacher.
Check out eWEEK.coms for the latest database news, reviews and analysis.