MySQL Users: SELECT wait_and_see FROM Oracle Acquisition
July 16, 2010One 
of our clients recently expressed concerns about “the absorption of MySQL into the wheel house of Oracle”. Fearing an expensive upgrade to Oracle Database would be the natural outcome of the acquisition the client was seeking guidance on the acquisition and possible alternatives.
We occasionally post highlights from a client/analyst conversation when we think you might also be able to benefit from the discussion. Here’s the summary of the conversation between the client and our Analyst:
First of all we don’t think the Oracle acquisition of SUN (and within that MySQL) presents any significant driver for existing MySQL customers to abandon ship within the near-term. By near-term we are looking 36 months out only. Beyond 36 months is outside any reasonable planning horizon for MySQL at this time.
In order to get the acquisition approved Oracle made binding commitments with the EU that ensure some protection of the investment in MySQL by customers. Specifically the relevant commitments from Oracle are;
- Commitment to enhance MySQL in the future under the GPL. Oracle shall continue to enhance MySQL and make subsequent versions of MySQL, including Version 6, available under the GPL. Oracle will not release any new, enhanced version of MySQL Enterprise Edition without contemporaneously releasing a new, also enhanced version of MySQL Community Edition licensed under the GPL. Oracle shall continue to make the source code of all versions of MySQL Community Edition publicly available at no charge.
- Support not mandatory. Customers will not be required to purchase support services from Oracle as a condition to obtaining a commercial license to MySQL.
- Increase spending on MySQL research and development. Oracle commits to make available appropriate funding for the MySQL continued development (GPL version and commercial version). During each of the next three years, Oracle will spend more on research and development (R&D) for the MySQL Global Business Unit than Sun spent in its most recent fiscal year (USD 24 million) preceding the closing of the transaction.
- MySQL Customer Advisory Board. No later than six months after the anniversary of the closing, Oracle will create and fund a customer advisory board, including in particular end users and embedded customers, to provide guidance and feedback on MySQL development priorities and other issues of importance to MySQL customers.
- MySQL Reference Manual. Oracle will continue to maintain, update and make available for download at no charge a MySQL Reference Manual similar in quality to that currently made available by Sun.
- Preserve Customer Choice for Support. Oracle will ensure that end-user and embedded customers paying for MySQL support subscriptions will be able to renew their subscriptions on an annual or multi-year basis, according to the customer’s preference.
- The geographic scope of these commitments shall be worldwide and these commitments shall continue until the fifth anniversary of the closing of the transaction.
(Source: http://www.oracle.com/us/corporate/press/042364 )
Based on these binding commitments Info-Tech sees that enterprises with existing MySQL implementations NOT having to immediately consider migration options. However, we caution that 36 months out this could be a very different situation depending on how Oracle executes MySQL strategies with the larger OpenSource community and more specificallywith its OEM partners. We believe the most drastic changes will be felt by the OEM’s first and will trickle downward from there. However internally with the MySQL team there will be change and upheaval (we’ve already seen Ken Jacobs leave Oracle as a result of management moves for the product) and for existing customers currently running with MySQL deployments while an interesting side-show, we don’t see that those high-level changes will have any immediate impact on them one way or the other.
PostgreSQL an alternative?
If the database decision is being made without a current implementation of MySQL and therefore the comparison to PostgreSQL is necessary then we suggest the following lens to examine the selection. Of course, like many decisions/choices in the OpenSource world the positions staked-out by fans of either can become rather shrill and dogmatic.
Our high-level guidance is as follows;
Functionality/Speed
Customer’s in the past ( also numerous benchmark reports) will highlight that MySQL from a throughput perspective is speedier than PostgreSQL. However, that is true only to a point. For small databases without complex PROCS MySQL is faster. When the size of the database becomes larger and more complex PROCS and QUERIES are being executed PostgreSQL (considering here the recent versions of the products) appears to our customers to be slightly faster due to the internal architecture.
There are new versions of both products available now therefore, the feature sets of the products should be examined directly using documentation available as Info-Tech hasn’t completed our in-depth comparison of the newest releases. Info-Tech suggests visiting the following links but keep in mind your unique application and processing needs requirements – some of the advantages of one versus the other will obviously entirely depend on how the product is deployed and used in your enterprise setting.
Data Integrity /Scale
MySQL has in the past experienced known issues that impacted Data Integrity. We’ve heard from Info-Tech customers who reported significant integrity issues with the MySQL product in previous releases and abandoned the product as a result. In contrast we’ve heard no similar issues with reliability at a Product level (other than the usual ‘garbage in garbage out’ issues which would have plagued any RDMS product deployed in those settings)with PostgreSQL . Overall, our customer feedback indicates that PostgreSQL provides much better tools and features to ensure data integrity of a production instance because the focus on integrity at a transaction level rather than at a bulk or table level with MySQL (which is the reason why for smaller instances MySQL will perform faster). MySQL gained significant functionally here with the integration of InnoDB but the benefits are primarily performance related and not contributors to transactional integrity.
Scalability – while there are some well documented ‘case studies’ of organizations who have massive amounts of data being administered with MySQL generally, speaking the customers we speak with have much larger datastores deployed with PostgreSQL. PostgreSQL scales better because of its transaction level architecture (referencing here our customers citing of the robust Transaction locking).
MySQL appears to somewhat lag with scalability because of the way ‘storage engines’, hash indexes, and clustered primary keys are leveraged. Those approaches do contribute to speed in smaller sets and simple queries but the bulk loading can cause performance issues at scale that can only be mitigated through ‘brute force’ with much larger/capable hardware. So this is a cost consideration going forward. For example, an 800GB instance on MySQL with complex transactions being applied will need larger more expensive hardware than PostgreSQL based on what we’ve seen deployed in customer settings.
Support/install base
MySQL has a much larger install base and community due to the nature of the usage it’s suitable for (websites, blogs, etc.). PostgreSQL has for many years been leveraged within enterprise IT shops so the relative install base and available community would be somewhat smaller.
However, the types of issues and challenges you’re likely to face as an enterprise would be beyond the average type of deployment represented by the community for MySQL. The PostgreSQL support knowledge available on the other hand is going to be predominately geared towards the real-world integration, scale and integrity issues faced by enterprise deployments.
Commercially available support for both products is fine and will support and enterprise well in either case. Therefore, at the ‘free’ or community support layer; for an enterprise the advantage goes to PostgreSQL. If you’re going to take the commercial support route then, the advantage there becomes less significant.
Bottom Line
- If you’re already running MySQL and are not experiencing issues but are concerned about the Oracle transaction; sit tight and revisit the decision in 36 months.
- If you’re trying to select one or the other for a large enterprise deployment with complex needs and high data integrity requirements; lean towards PostgreSQL.
- If you’re going to take PostgreSQL as described in the point directly above and you’re going to engage commercial support contracts then, you really should look as well at Microsoft SQL Server 2008 and/or Oracle Database 11g versions. When you start adding commercial support to the cost model – and given the range of other integration options it becomes less of a clear win for PostgreSQL. While this is can be a tough point for Open Source shops to concede but, there are situations where either SQL Server 2008 or Oracle 11g will be a better building block for your architecture.
See also:
MySQL 5.0: The DBMS That Would Be King
Include MS SQL Server 2008 in Consolidation Plans for Cost Reduction
This entry was posted in Advisory, Analyst's Angle and tagged data-center, database, Infrastructure, microsoft, open-source, Oracle. Bookmark the permalink.
Comments are closed.