Since the Sun acquisition was announced I continue to get questions on how it will impact MySQL. This seems to be mainly as a result of the close affinity between PHP and MySQL. I must admit that while I had a lot of immediate thoughts when the IBM/Sun rumor was floating around, I have had a bit of a harder time figuring out what the Oracle/Sun acquisition means for the various pieces of Sun's business including MySQL.
Like many I believe that Oracle would not want to kill MySQL and that steering it more towards the SQL Server market as opposed to Oracle DB could make a lot of sense for Oracle. After all, MySQL definitely competes with SQL Server on ease-of-use and some of the mainstream relational DB features, while for the very high-end features, Oracle is still way ahead (Real Application Clusters, Database Resident Connection Pooling, Backup & Recovery, Data Mining, OLAP). But what will it take to steer MySQL towards SQL Server? Invest in better Windows packaging? Improve performance on Windows? Invest in native management UIs? Build a strong Visual Studio plug-in for MySQL? Make .NET-based applications like Dotnetnuke work better with MySQL? I think it means all of the above and probably some additions I didn’t think of. All that said, I have now changed my mind and believe this is not where the big opportunity lies for Oracle although I see it as a strong secondary strategy and believe Oracle is likely to benefit from executing in this direction regardless.
The other assumption I heard from many was that MySQL would be the entry version for Oracle into accounts. But how would that work in real life? Would they over time build Oracle API (OCI) compatibility into MySQL and hope that at some point people will install Oracle, migrate their data from MySQL to Oracle, and rewrite their applications to access Oracle instead of MySQL? This does make some good sense for Oracle especially as it’d give them a chance to build mindshare and awareness among developers for the their brand. However, brand awareness and account foot print is not enough and I believe this simplistic view does not take into account the user experience. For the user there would be too many challenges in having to swap out the database with a new one, do the data migration and port the application from MySQL to Oracle APIs. In fact, it could be such a pain that users would likely prefer to invest time in working around the MySQL limitations at the application layer instead of doing a migration especially if they are in a time sensitive situation (which MySQL users have been doing successfully for years).
A few days ago I finally figured out what I would do if I were Oracle. I would go out and build an Oracle storage engine for MySQL similar to the DB2 for i storage engine MySQL developed with IBM.(http://solutions.mysql.com/engines/ibm_db2_storage_engine.html) Just think of it as using MySQL as a front-end to Oracle and immediately leveraging the eco-system of developers, applications and tools that support MySQL (see Diagram 1 below). I would then continue to push MySQL’s adoption as much as possible and build out the features that will continue to drive broad adoption.
At this point MySQL would tie directly into Oracle and immediately when a customer needs an Enterprise-grade features like clustering, hot-backup, BI, etc. they could just sell their “Oracle DB Infrastructure” which would support MySQL via the Oracle storage engine. The result would be that without changing any application code you would immediately tie into Oracle and then start leveraging some of Oracle’s unique capabilities.
Of course once that happens, Oracle sells another Oracle license, the data sits in Oracle (typically that means it never migrates anywhere else) and over time other applications will likely leverage this data either via the MySQL interface or directly via OCI (Oracle Client Interface).
What is there left to do for Oracle? No need to focus on investing in Enterprise-grade features for MySQL. They just need to make sure that there’s a good Oracle storage engine which enables a click of a button upgrade from MySQL(InnoDB) to MySQL(Oracle). Seamless to the application and the developer. You get the best of both worlds.
This also makes the CIO extremely happy. They would now have the ability to keep business-critical and sensitive data in Oracle while keeping the developers in their organization happy by letting them use MySQL as the front-end.
I believe by making the right investments in MySQL, Oracle can not only grow the MySQL business but also the Oracle DB business. And if played right it may actually enable Oracle to be less aggressive on the business side with the MySQL products which could also make MySQL's customers and community happier.
Disclaimer: I have no bias towards any of these databases and am only stating what I'd do if I were Oracle. In PHP we have great MySQL , Oracle and SQL Server support. We are the corporate Web glue and will always make it easy for our users to leverage their data sources no matter what they are…
Q&A:
What about the additional latency to drive transactions to another database?
While this would likely add some additional overhead to a simple throughput benchmark I believe in real-world scalability scenarios some of Oracle's solutions like RAC, TimesTen in-memory DB, connection pooling, etc. would potentially address some common objections. But then again I am not a DB engineer so I may be completely wrong.
And what happens with Falcon?
Now Oracle owns MySQL and InnoDB there's no need for it anymore.
And what about the Open Database Alliance (http://opendatabasealliance.com/)?
That may be some nuisance for Oracle but as it would be "open" the Oracle storage engine could work with that too and as stated previously such a strategy may actually enable Oracle to be more community focused than Sun and MySQL AB.
Diagram 1:
