In two words: online operations. In a paragraph: Forget partitioning, row-based replication and events. The big reasons most people are going to salivate over 5.1, and probably start plans to upgrade now, are the online operations:

• online ALTER TABLE for column rename, column default value change, and adding values to the end of an ENUM/SET
• Online, table-based logging. No more need to restart your server to enable or change the general or slow query logs. You can have the standard file-based output or choose a table format…which you can query.

(more…)

The MySQL Community version is different in theory from the Enterprise version in relation to the following points:

0) It’s free
1) It has community patches
2) It is released less often
3) It is tested less strictly

In reality, the first two differences are not applicable — the binaries and source code for Enterprise can be freely and legally downloaded at http://mirror.provenscaling.com/mysql/enterprise/. The process for adding community patches to the MySQL source code has not been changed sufficiently to be able to actually add community patches and encourage more community development.

I understand that MySQL (and now Sun) needs to make money. I also understand that development takes a lot of effort, and seeing an ROI is important. The Community/Enterprise split was designed to have tradeoffs on both sides. However, currently there is no benefit to running the Community version.

While I would love to magically make community contributions easy to put into a Community version of MySQL, logistically that’s not possible right now. I do have a solution that is possible right now, that takes very few additional resources, and is something I think will be acceptable to the MySQL community and to Sun — assuming the MySQL executives can admit that the Community version has not been working out.

I propose to make the Community release an older version of an Enterprise release. In this way, Enterprise users still get value in having bugs fixed and features added first, and Community users can choose to upgrade if they want the latest features. There is very little overhead in having Community releases, with no overhead in having to manage two trees/branches/whatever from both a code and build standpoint. Maintaining the promise of immediate security releases, 4 code releases per year and 2 binary releases per year becomes trivial.

The question is, of course, how far back the Community version should go. And should there be a delay (ie, release the January Enterprise version as the June Community version) or not?

I recommend that security releases be immediate (as they currently are) and for all other releases there should be a delay of at least 6 months, perhaps 1 year. Certainly that’s enough of an incentive to get customers to upgrade without having folks feel like the Community ersion is crippleware.

What do folks think of this as a solution to the Enterprise/Community split dilemma?

In http://www.mysqlperformanceblog.com/2008/07/01/should-we-proclaim-mysql-community-edition-dead/, Peter Zaitsev wonders if MySQL’s community edition is dead.

The title of Peter’s inquiry is somewhat misleading, as the database itself works fine. He clarifies a bit with, “there suppose to be 2 yearly binary releases (which are overdue) and 4 predictable yearly source releases, which we have not seen either.” I thought it was clear that “2 per year” doesn’t mean “one every six months”. It’s been eight months, sure. And I don’t actually believe that MySQL is going to have one source release per month until November, to make up for the lack of source releases. However, it’s certainly possible, if not probable.

The fact remains, however, that if you’re just looking for stable, recent, binary MySQL Community release, you might not find it. MySQL offers two out of three — stable and binary Community releases. Not recent, but I think it’s okay to charge for the most up-to-date version. In my experience only about half of the production environments out there have switched to 5.0, and many are running 4.1 and 4.0 still.

At the low end, a license costs just under USD$600. The requirement to buy a license to get the most recent version is a mere inconvenience, not a business-stopper. It’s not like MySQL is forcing everyone to run on version 3.23 unless they pay $10,000 per license. Charging a modest amount for the most up-to-date version is not a bad thing.

It would be nice to have been aware of that ahead of time, but MySQL as a company has not been so great at organizing and having all its ducks in a row. In fact this is where I hope Sun can really help MySQL out, as it has a reputation (a deserved one, in my experience) of being more highly organized.

Have you heard of Hanlon’s razor? “Never attribute to malice that which can be adequately explained by stupidity.”

(more…)