Document that MariaDB works, too

+1

It's quite a shame with what's happening to MySQL.

I agree with the idea, but until the major distributions don't offer mariaDB with their default packages, we can only offer it as an alternative.
(Maybe as a first choice and mysql as an alternative?)

Given recent experience in #772678: Database default collation is not respected, this may indeed be a valid and good thing to do.

Did you test whether D7 runs on MariaDB and tests are passing?

I would agree with replacing all the "MySQL" in our documentation by "MySQL/MariaDB". Of course all the tests pass on MariaDB, most of our test slaves already run on it :)

I like Damien's suggestion - we should do that in core and also /requirements, release announcements etc.

Isn't to soon?

a) Are there other drop-in replacements as well, besides MariaDB (and this is the first time I have ever heard of MariaDB)? If there are, I think maybe the proper wording should be "MySQL or a drop-in replacement, such as MariaDB", or something to that effect. Unless this is really a political campaign and not a functionality issue.

b) Does MariaDB (or other drop-ins, if they exist) work with all of the PHP mysql db functions?

c) Have we verified that the D7 test base runs with MariaDB?

d) Is the command line command for this database mariadb or still mysql? If it has changed, we would need to make extensive changes in our how-to docs, or at least say "If you are using MariaDB or another drop-in replacement, replace 'mysql' with 'mariadb' or the equivalent command."

e) We also need to consider putting something about this on the Requirements page in the Handbook.
http://drupal.org/requirements

Actually... My inclination would be to *only* mention the database alternatives on the d.o requirements page and in install.txt's requirements section, rather than trying to go through and find all references to MySQL everywhere in all of our help and text (e.g. error strings from install.php, etc.).

There is no way this is a major issue. Drupal 7 supports MySQL. We're not adding support for another DB that requires code changes to core; we are WAY past code freeze. if it requires no code changes but just documentation that "oh yeah, MariaDB works, too", then it is not major. I'd almost say it's minor.

MariaDB is one of a number of MySQL forks that appeared after Sun bought MySQL, and later Oracle bought Sun. Why should we favor that one over any others?

If anything, we document "Some MySQL-compatible databases will work as well using the MySQL driver" and stick that somewhere, and that's the end of it.

At a minimum, before recommending a particular drop-in replacement, I think we would at least need to verify that the D7 tests work with that drop-in replacement, and have a test server continually verifying it. But I doubt we want to get into the business of doing that.

+1 to Crell's suggestion in #8, if someone can verify that nothing needs to be done in core to run D7 on these drop-in replacements. IMO, s/stick that somewhere/put it on the d.o requirements page and in install.txt's requirements section/.

Everybody, please *read* and understand both the original post and #4. No, this issue is not about "supporting another DB that requires code changes to core". It's not about promoting a fork of MySQL, but a drop-in replacement. MariaDB is what MySQL should be if it was properly maintained by Sun/Oracle. It is 100% compatible with the corresponding MySQL version. And yes, Drupal works perfectly with it. Even more, most of our tests clients run MariaDB *already*.

And even if there have been several forks of MySQL, MariaDB is the only one that aims at being a drop-in replacement. We should *also* be forward thinking and start supporting Drizzle, but that's another story completely (and we have another issue for this).

Speaking for myself, it's not that I didn't *read* the issue, it's that I didn't understand everything in it until your most recent comments Damien. So thanks for the clarifications that you just added, that (a) MariaDB is the only DB that aims at drop-in, (b) we are already using it for tests.

So.

Here's a concrete suggestion of what to do about this, in the form of the patch. And as noted above, we should also add something similar to http://drupal.org/requirements

Since the MariaDB project is apparently a drop-in replacement, all of its commands and php functions etc. must also say MySQL all over them, so I think just a note in the install documentation is enough of a mention.

Also note that install.txt is kind of a mess, as far as cosmetics (line wrapping, etc.). If the patch in
#683892: Text clean-up of INSTALL.txt
goes in to clean up the mess, the above patch will need a reroll.

Why isn't that a proper list?

Text looks fine... to me this *feels* RTBC.

I actually don't like the patch in #14 much:
- We don't normally put commas after list items, see http://drupal.org/node/1354#general (list section)
- List items should start with capital letters
- Since all the other doc mentions MySQL, I think MariaDB should be included and listed as a replacement, as I did in #12 patch, so people realize it's an equivalent.

For what its worth, I think this is a great idea. Right now we have basically these forks:

MySQL/ORACLE
MySQL/MariaDB (Monty + a lot of the original mysql devs are here)
MySQL/Percona (Are partners of MariaDB and say they are going to switch to distributing it)
MySQL/Ourdelta (Are already just redistributing MariaDB)
MySQL/Drizzle (Not production ready)

MariaDB is a drop in replacement and then will be adding features, for example current work in the next -dev is going to support virtual columns. Ala document store. However, it is entirely compatible with "MySQL". The project is headed by Monty, has most of the original devs back. It is fairly logical to start mentioning it in our documentation.

We are using MariaDB with its default XtraDB engine without any issues on all our servers and all Drupal distros since over 5 months now. Highly recommended for sure.

In what ways is MariaDB better than MySQL that justifies making it a recommendation, other than "well the main devs went over there and we don't like big companies that have too many database products"? I am not comfortable recommending an alternative DB unless I know why we recommend it.

Is it demonstrably faster? Does it demonstrably scale better? Has it been independently verified to have fewer bugs?

@jhodgdon: sorry for the tone of #10, #11. I wrote those on the iphone at a café...

If it's mostly a question of bugfixes, then our "recommendation" should be something like "Users may also wish to look at MariaDB, a fully compatible MySQL variant that is considered by some to be more stable but still fully compatible with Drupal's MySQL driver."

Just listing it as compatible (as the patches above do) is also fine.

Actually, the version number I put in there is entirely made up. Likely needs correction.

OK, someone needs to figure out which MariaDB version to recommend/require:
http://askmonty.org/wiki/MariaDB:Download#All_Releases

They don't have a stable 5.2 at this point, just a beta, and the current stable release is 5.1.47. Which version is required for Drupal compatibility?

Meanwhile, if you want to go this route with the patch, here's a cleaned up version that follows our list-making standards.

Actually... My inclination would be to *only* mention the database alternatives on the d.o requirements page and in install.txt's requirements section, rather than trying to go through and find all references to MySQL everywhere in all of our help and text (e.g. error strings from install.php, etc.).

As far as I know, there is only one place in the code that controls the use of "MySQL" in user interface text:

class DatabaseTasks_mysql extends DatabaseTasks {
  protected $pdoDriver = 'mysql';
  public function name() {
    return 'MySQL';
  }
}

So it wouldn't be hard to change if we wanted to.

And this controls what people see on the database selection page in the installer, when they are choosing which database driver to use (see the attached screenshot). So if the driver is compatible with more than just MySQL, perhaps its user-facing name should be changed in some way. Otherwise it might be odd that we tell people MariaDB works but then only give them a chance to select "MySQL" when they actually go to install Drupal?

If we change this, I would vote for "MySQL or equivalent". At least for now, MySQL is what people have actually heard of. With the language proposed in #27, it's at least clear in the install.txt that MariaDB is a MySQL equivalent.

Hm, I took a closer look at where this gets used and it turns out we do reuse the driver name in all sorts of error messages, like this one:

'Failed to <strong>CREATE</strong> a test table on your %name database server with the command %query. %name reports the following message: %error.<p>Are you sure the configured username has the necessary %name permissions to create tables in the database?</p>'

Imagine that sentence with %name replaced by "MySQL / MariaDB or equivalent" - not so good :)

Frankly, we could simplify it by removing most of those references to %name (they are overkill anyway), although that would make the patch bigger. I'll give it a shot to see what it looks like. We could go back to just doing it in INSTALL.txt, but frankly, the number of people who read that file in the first place is probably pretty small, so for all practical purposes we would then be confusing people by only recommending MySQL...

By the way, in "MySQL / MariaDB", I don't think there should be spaces before and after the slash.

So, the attached is basically what we'd need to display it in the UI and have it make sense, if we want to do that.

(Frankly, we could probably get rid of even more of those %name references if we wanted to; they are mostly extraneous. But this is the minimum.)

MariaDB is fully compatible with MySQL and is recommended instead of MySQL.

I instaled MariaDB, but now the doubt is, what engine is recomended, innodb engine, or MARIA/ARIA engine?

+1 for the patch in #32. I think the messages are fine.

As a note, if we do this, we also need to update the Requirements page in the Handbook accordingly.

So I think at this point, the patch is technically/documentation fine. It's a purely political decision whether we should recommend MariaDB. I cannot make this decision; marking RTBC so Dries/webchick can decide.

Let's gather some facts and links (I'm waiting on your list chx ;-)
http://askmonty.org/wiki/MariaDB_versus_MySQL

Subscribed.

+        'Failed to <strong>CREATE</strong> a test table on your %name database server with the command %query...,
+        'Failed to <strong>INSERT</strong> a value into a test table on your %name database server...
+        'Failed to <strong>UPDATE</strong> a value in a test table on your %name database server...
+        'Failed to <strong>DELETE</strong> a value from a test table on your %name database server...
+        'Failed to <strong>DROP</strong> a test table from your %name database server...
+      $this->fail(st('Failed to connect to your %name database server...

Those all still contain %name.

That was intentional. If you read the whole patch, you will see that these messages will now be something like this:

Failed to INSERT a value into a test table on your MySQL/MariaDB or equivalent database server.

Or should I say: I thought it was intentional and I felt that the result was good.

How much collective experience do we (Drupal users in general and the DB team in particular) have with MariaDB? I've never used it, but cannot speak for anyone else.

I'm fine with saying it's compatible, but I do not yet have enough knowledge or experience to feel comfortable putting my name (either individually or collectively) on a recommendation for a product I've never used.

The test bots have been running it for months. Drupal.org runs it. Examiner runs it. That's a small number of people doing the administration (unless there's lots of other examples I don't know of we could add to that list), but very large / well tested installations.

I also just installed it on localhost, although haven't had much time to do much on localhost this past week, and it was just a case of adding a new line to /etc/apt/sources.list, otherwise everything is the same.

I'm going to go out on a limb and suggest that perhaps it is important to realize who we are writing those documents and help text snippets for.

Anyone we can trust to go out and properly install MariaDB on their server (THEIR server!) we can also trust to understand that references to 'MySQL' also cover MariaDB. Users who are working on servers managed by other administrators, or users working with shared hosting or managed VPS solutions, are unlikely to have the luxury of switching to MariaDB for ideological or technical reasons. The odds of them running on a server that has MariaDB, and believing that they can't use Drupal because of it, is pretty minimal: they're more likely to be confused by the "MySQL/MariaDB" change.

I think it would be fantastic for us to publicly note that we support the MariaDB project, and promote them. I think it would be great if our Readme file made our compatibility with drop-in MySQL replacements explicit, but going through to change all of our on-screen language simply to show solidarity with a new OSS project strikes me as a bad choice.

I can't speak for anyone else but I certainly didn't add those parts to the patch in order to show solidarity (?), but rather to be accurate. We shouldn't tell people in INSTALL.txt that they can use MariaDB, and then give them no way to select that on installation. And the names of our database drivers should reflect the software that they work with...

Why do you assume that only technically-oriented people will have the option to use MariaDB and everyone else will be using MySQL? Drupal 7 will have a long lifetime; who knows what will happen with regards to that.

The only part of the patch that is in any way ideological is the part that says we recommend MariaDB over MySQL. I agree with other comments above that it would be a good idea to have more supporting evidence (for example, at least the bugfix list chx referred to) before going ahead with that.

The only part of the patch that is in any way ideological is the part that says we recommend MariaDB over MySQL. I agree with other comments above that it would be a good idea to have more supporting evidence (for example, at least the bugfix list chx referred to) before going ahead with that.

Fair point - thanks for clarifying. I just think that our helptext already tends towards the arcane, and it takes hard work to keep it as simple and straightforward as possible. The odds of someone being confused by 'MySQL' when they already know enough to use MariaDB are very, very slim and not worth the complication in our on-screen helptext. Documenting in our INSTALL.txt that 'MySQL' in the user interface also covers any transparently compatible drop-in replacements for MySQL, like MariaDB, seems like a worthwhile note. But because MariaDB aims to be a drop-in replacement, its entire purpose is to be usable in places where software claims to only work with MySQL.

I agree with Eaton here. MariaDB is too new and too edge-case at this point to confuse users with in on-screen text. I'm hardly a casual user and I didn't know that anyone was running Drupal with MariaDB until this thread. At this point MariaDB is still a high-end-admin-only tool because only high-end-admins have root to install it. Whether or not that will be the case in 3-4 years no one here can even speculate; right now, that's the situation.

We should leave the documentation in the INSTALL.txt file and on the site to read along the lines of "Drupal needs one of the following Databases: MySQL, Postgres, SQLite, or a MySQL-compatible DB such as MariaDB."

At this point I am increasingly less comfortable doing anything more than that. The vast majority of Drupal installers are still people working with shared hosting (see: Dries' SF keynote). Complicating the UI to support only the high-end minority is a bad trade-off.

Good evening fellow Drupalistas.

Before commenting, I really need to introduce myself for purposes of full disclosure. On drupal.org I usually wear the hat of a humble maintainer of the Footnotes module. I've also submitted a bug fix against D7 core (url filter) which is not yet committed. My drupal involvement predates my career with MySQL and MariaDB. I have worked for MySQL AB and Sun, and now work with Monty on MariaDB. On top of that I'm "politically" active in issues around open source vs closed source vs "open core". So all this is to say, if I were to express an opinion on this topic, it would be a very biased one.

Even so, I of course know a lot of information about both MySQL and MariaDB so I just wanted to make an appearance on this thread. If there are any questions I'm happy to answer.

In particular:

1/ I'm absolutely extatic to hear that drupal.org now runs on MariaDB and that you also run the test slaves with it! On behalf of all MariaDB hackers, thank you!

2/ I would like to confirm that comment #17 is an accurate description of the current state of the MySQL universe. Percona Server continues alive and well, but other forks can be considered obsolete. (Drizzle is not considered at all, it is not aiming to be fully MySQL compatible, you should consider it separately.) Percona Server is a very focused project of Percona aimed primarily at their own customers, for instance before we at MariaDB forced them to, they didn't even compile on Windows. When I left for paternity leave, there were still a list of patches to commit from Percona, but essentially MariaDB will be a superset of Percona Server. (Maybe in the future it is more correct to consider Percona a version of MariaDB than a version of MySQL.)

3/ MariaDB 5.1.x is very similar to MySQL 5.1. Both listen on port 3306, you have the same command line tools, PHP drivers etc. In fact, we have not introduced any "mariadb" commands or drivers, though we intend to do that.

In MariaDB 5.1 the main advantage over MySQL 5.1 is significantly improved (InnoDB) performance. MySQL now ships and supports a separate module called "InnoDB plugin", which you can load into your MySQL 5.1 to replace the original/default InnoDB and also get much better performance. The performance of MariaDB 5.1 and MySQL 5.1 + InnoDB plugin should be roughly equivalent (once you know how to find and load the plugin). Beyond this MariaDB 5.1 contains some small feature patches from the MySQL community that were ignored by MySQL plus the rather interesting PBXT engine. MariaDB 5.2 is about to go RC and will contain many more such patches. 5.3 is still in development, it's main new feature will be seriously improved performance on complex sub-queries, this is probably not immediately interesting for Drupal (as you are most likely not using subqueries today due to the performance hit). MariaDB will continue to merge from new MySQL releases, so it will always continue whatever is in recent MySQL releases (assuming MySQL remains open source, of course). We have better test coverage now, so occasionally we reject some commits from MySQL that don't pass our tests (or review) - but this is where my opinion starts to become biased :-)

Like above, this link: http://askmonty.org/wiki/MariaDB_versus_MySQL (see also 5.1 and 5.2 release notes) goes into more details.

4/ Use MariaDB as you would use MySQL. Use InnoDB, feel free to ignore the ARIA engine (formerly MARIA engine), PBXT engine, etc.

5/ If I were to allow myself to make one suggestion, I think the "or equivalent" text is superfluous in the latest patch - this follows from point 2/. (If you want to be polite, you could of course approach Percona for their opinion, but they are really the only other fork still alive.) Of course, if the intent is to be "future proof" against the hypothetical scenario that we will see more MySQL forks within Drupal7 lifetime, then I understand, but just "MySQL/MariaDB" would be much shorter, so "or equivalent" is a price to pay for guarding against a purely hypothetical scenario.

6/ MariaDB and mariadb.org will be managed in a legal sense by the Open Database Alliance, a non-profit. (However, a few things still need to happen to make this reality, I'm actually responsible for that.) As a development project it is pretty much a bunch of hackers committing to bzr trees on Launchpad :-)

UPDATE 2010-11-25: This is a dead thread already, but just for those who will later stumble upon this from google or whatever, I feel I need to correct point /6/ above. Monty Program has now decided to keep the domain and trademark, and ODBA will not become the host of MariaDB, contrary to what was the earlier plan. (http://openlife.cc/blogs/2010/november/leaving-monty-program-and-mariadb for more info)

As a personal comment, if Drupal were to take the effort of changing a string from "MySQL" to "MySQL/MariaDB" in your user interface, that visibility is for sure helpful to MariaDB, on top of being mentioned in the INSTALL.txt/Requirements. Those that install MariaDB today know that it is 100% compatible with anything that says MySQL, however those that don't yet know this and still use MySQL without thinking about it, would get a powerful clue from reading "MySQL/MariaDB". Over time, you may also start running into people that have heard of MariaDB and will look for it, so in the medium to long term it should be useful to have it visible, rather than just telling people to look for "MySQL" instead.

I will stay tuned on this thread in case there are any further questions for me.

I think the above was cross-posted.

Sounds like the proper status is "needs review".

Re #47, Getting rid of the "or equivalent" and going with "MySQL or MariaDB" makes sense to me.

Re the previous comments: The problem we have here is that we have to make some kind of prediction of what will happen with MariaDB, because Drupal 7 will be out for a long time and we can't really break strings later on to fix this. So I'd at least think we should include the string changes here (even if for some reason we don't change the driver name itself) to remove the excessive use of %name, so as to make this more future-proof and generally allow more flexible driver names (should they arise at some point).

Hi there, nobody here knows me but I wanted to chime in from a sysadmins perspective. What #43 said but most importantly #2: there are no packages for the major distributions which means that if we use MariaDB, we aren't getting automated security patching from upstream. What if you're administering 250 servers and need to patch? Sure, we can devise an automated way to patch sourcecode everywhere and recompile on 250 servers - but distributions already do this by distributing patched packages - it's a big part of why we have distros.

It seems most of this would be better handled at the distro level, e.g. Ubuntu has drupal6 packages which depend on mysql-client. Once MariaDB gets into the distribution then "mariadb-client" could become the dependency instead, perhaps the preferred one over mysql.

What I'd much rather see is some outreach from the Drupal community to the Ubuntu maintainers (if not already).

RE #49: We could remove %name even more. I am not sure why it's actually necessary to have the database name printing in any of those error messages?

I've re-read the whole comment stream and I think we should go ahead with some form of this patch. 'Mysql or MariaDB' sounds good to me. I also think it is not necessary to mention DB driver name in the error msg (its a minor point though).

@zeugmatis, in the ourdelta.org we can have linux repository for RedHat/CentOS/Ubuntu/Debian Linux.

http://mirror.ourdelta.org/deb/dists/lenny/mariadb-ourdelta/
http://mirror.ourdelta.org/deb/dists/lucid/mariadb-ourdelta/
http://master.ourdelta.org/yum/CentOS-MySQL50/5Server/x86_64/RPMS/

@Crell - anyone with a VPS or a localhost development environment has root, as you say this is not the case with the majority of Drupal users, but neither is it the sole preserve of super-admins.

There are going to be plenty of people who are capable of learning about MariaDB and installing it, but for whatever reason either haven't heard of MariaDB or don't know it's a straight drop-in, this includes me a couple of months ago (I only really noticed it when it identified itself on the mysql cli on my examiner sandbox).

On the distributions, the first thing I did when I saw this thread was look to see if ubuntu supported it yet, it doesn't, but there's work to include it in debian - https://wiki.ubuntu.com/Lucid-MariaDB-Inclusion and https://bugs.launchpad.net/debian/+bug/519478

In terms of using 'MySQL or MariaDB' being confusing, this is possible but we only mention MySQL specifically in one or two places. In those cases I'm more worried about novice users who happen to have sqlite installed on their hosting account and use that because they're only going to have a small site (or similar). Even if MariaDB gets into the major distributions people aren't going to have it as a choice unless they explicitly install it.

I can see why "MySQL/MariaDB or equivalent" (in the current patch) might be confusing: The meaning of the slash is somewhat ambiguous, and people might read it and think that their MySQL installation won't work with Drupal on its own, but rather needs something called MariaDB to be added to it :)

However, if we went with "MySQL or MariaDB" I think that removes most of the potential for confusion?

***

RE #49: We could remove %name even more. I am not sure why it's actually necessary to have the database name printing in any of those error messages?

Right, I originally only removed it in the places where it absolutely needed to go so as to try to do the minimum necessary change. I agree it could be removed other places, and may be a good idea to do that here after all, if our goal now is to allow the driver name to be as flexible as possible.

Yes, apologies for accidentally changing the status. I must have pressed arrow down while in that field.

Since I'm here, I may again answer some questions. I hope this gives you a taste of the MariaDB project's vision to be responsive to the open source community :-)

About making predictions (#49)
For the team at Monty Program, Monty has committed funds for a 5 year plan, of which the first year was now used. So the worst case is that MariaDB keeps developing as it has done now for another 4 years (with customer revenue, the time is of course extended). Of course, we hope that the community quickly grows so that Monty's funding becomes a non-issue before that. Even in the best case, Monty Program itself will never be the size of MySQL AB, we *want* a community of other companies in MariaDB. And as you can see, both the people behind Percona and OurDelta contribute to MariaDB already.

For the MySQL side you have Oracle's "non-binding" commitment to the EU to keep developing MySQL for the next 5 years, including a GPL "Community" version which may however not contain all the features of a closed "Enterprise" version. Beyond this we don't have much solid information from Oracle, their policy seems to be that when they release something they'll let you know.

So those would be the worst case scenarios for either. Realistically, both will exist long into the future and for the next 1-2 years people will just use MySQL 5.1 without worrying too much, while MariaDB adoption increases.

About Linux packages (#50)
Currently openSuse and Gentoo ships MariaDB in their official repositories. For Debian/Ubuntu we needed to fix our .deb packaging before proceeding there, but work with other distributions is ongoing.

We do however provide apt and yum repositories ourselves, you can find links and instructions here:
http://askmonty.org/wiki/MariaDB:Download#Packages

The ourdelta.org infrastructure gets the packages straight from our build system now and in fact, this is the recommended way to install.

So what we need is a patch that:

1) Mentions that MariaDB can be used in place of MySQL.
2) Does not recommend or endorse MariaDB over MySQL.
3) Doesn't confuse the heck out of the average user that doesn't know what this "Mariadbee" thing is.

Who's on it? :-)

Me!

And it even has docs. :-) I am +1 on #58 unless someone else has an objection.

Um, I'm completely immersed in the MySQL community, and I do not understand why you are assuming Oracle owning MySQL means that "the future of MySQL is cast into doubt".

The leaders of MySQL, namely Monty Widenius and Brian Aker, left before the merger was even announced -- they left during the Sun years (Monty left completely, and Brian worked at Sun but left the MySQL world to work on Drizzle). The lead developers of InnoDB have been Oracle employees since Oracle acquired Innobase in 2006, and are still Oracle employees.

Oracle has *already* helped stabilize and improve MySQL's codebase. Oracle has been a driving factor in MySQL 5.5.

This is fear, uncertainty and doubt, pure and simple (AKA FUD). While I'm sure MariaDB is good, it had its first GA in Feb 2010, just a few months ago, and has yet to prove it can last for years, as MySQL has.

MariaDB also has spotty documentation -- only some of the documentation is GPL'd (that in the mysql client's help section) and so switching to MariaDB means documentation in an unknown state.

( see http://askmonty.org/wiki/MariaDB::MergingMySQL#Merging_documentation_fro... )

I think Monty will make great code in MariaDB as he did originally with MySQL, but I think it's too soon. In the DBA world we know how flawed MySQL is, and I actually look forward to have new, fresh faces programming MySQL, who will hopefully design features and fix code much better than the previous developers did.

I don't see MySQL dying any time soon, and it has great documentation, is already in use and has a large population of DBAs who have years of experience using it. MariaDB's support model (http://askmonty.org/wiki/Support) is that the Monty Program will patch the code if needed, but technical support is sent to partners, and those partners get kickbacks (the Open Database Alliance is basically a group that throws money around and refers each other with kickbacks, see http://odba.org/about/vendors/).

As a note, I will mention that the Percona MySQL build is a series of patches to MySQL, and thus is drop-in compatible.

Unlike MariaDB, the Percona MySQL build has been around for a few years (although just a few). Like MariaDB, it does not have complete documentation (but because it's a patch set to MySQL it's not expected to have full documentation, just documentation for its patches).

Also, the Percona MySQL build is being used in production environments; about 30% of my clients right now are using it, and it shows performance improvements just as a drop-in replacement, even without turning on any of the new features or tweaking the new knobs the Percona build gives.

Ourdelta is just a package and redistribution (just like Linux or Debian packages and redistributes MySQL).

MySQL/Drizzle -- this is not going to be even close to MySQL, and already uses some different data types, so migrating a database from MySQL to Drizzle is not trivial (disclosure: I was a part of the Drizzle community from May 2008 until a few months ago, when I just got too busy to keep up, and I actually intend to re-join in a few months).

If there are some politics and for some reason you're morally opposed to MySQL, I would actually recommend Percona's build, as it's proven stable and performant. But really, there's no reason to switch to anything else, except if you're completely paranoid. Oracle's not closing the source of MySQL, they make too much money from it already.

Everyone knows that MySQL is *not* an Oracle competitor, including the EU commission that determined that Oracle buying MySQL did not "significantly impede effective competition" (see http://europa.eu/rapid/pressReleasesAction.do?reference=IP/10/40 and pick your language).

Also, Oracle has promised that for *at least* the next 5 years they will continue to put more resources behind MySQL - http://www.oracle.com/us/corporate/press/042364

Nobody can know what will happen in 5 years, perhaps Postgres will become more popular by then, but there's no reason for Oracle to close MySQL's source; if they did that they'd lose ALL the business they have with support, training and certification. Nobody would migrate from MySQL to Oracle if they closed the source, they'd all just use other builds, and anyway, that's in the *very unlikely* scenario *in 5 years*.

There are lot more possible derivatives then those already listed.

While MySQL is now owned by Oracle, MySQL is still and will always be open source. In theory that may change in the future, however all current versions are under GPL and this can not change. Oracle has committed to ongoing development of MySQL. While I'm not advocating Oracle as a company, I'm representing the voice of the MySQL community as one of the most recognized MySQL community members.

I would propose that if your were even to consider an option, other then "MySQL", then a "MySQL Family", i.e. those products that communicate via the MySQL protocol.

For reference, MariaDB is known as the most compatible version of MySQL. It is by it's own definition MySQL, so interchanging this behind the scenes is possible for any installations. They will still talk MySQL syntax using the MySQL Protocol.

To elect to choose MariaDB over MySQL will only provide confusion to millions of user that know and understand the LAMP stack.

The talk about storage engines is an entire different discussion.

Changing title to better reflect the status of the conversation.

Changing the status yet again, as the Percona build is also compatible -- it's just patches to MySQL.

Those of you protesting in the last few comments: Please take a look at the actual proposed patch in #58. The language in there does not actually recommend MariaDB. At this time, we know that Drupal works well with MariaDB, since many of our testing servers and drupal.org are using it. So we can list it as a compatible choice. Others, we haven't tested...

For reference, the patch above just says in the INSTALL.txt:

+- One of the following databases:
+  - MySQL 5.0.15 (or greater) (http://www.mysql.com/).
+  - MariaDB 5.1.44 (or greater) (http://mariadb.org/). MariaDB is a fully
+    compatible drop-in replacement for MySQL.

and it says for the DB string:

   public function name() {
-    return 'MySQL';
+    return 'MySQL, MariaDB, or equivalent';

So, Crell and I are happy with the patch in #58. Any other opinions directly referencing that patch?

Eh, @sheeri and @ronaldbradford, while you certainly have both credentials and knowledge to share about MySQL, wouldn't it have been appropriate for you too to disclose your Oracle ACE connections first and to what extent that obligates (or doesn't?) you to blog and speak in the community about the relevant Oracle product? (Yes, sheeri, I listen to your talks :-)

I don't think this is an appropriate place to get into a discussion who has the best developers or what the EU may have thought (hint, link to the official decision, not a press release, if you are going that route, but perhaps not in this thread). But I think this discussion deserves that the following factual errors are corrected:

* Percona Server does come in many binaries, it is not a patch set. See http://www.percona.com/downloads/Percona-Server-5.1/LATEST/ I don't know if they still maintain the source as a patch set. (This may not be very relevant to this discussion, just wanting to be fair to each fork/flavor/distribution.) I disagree that Percona would be an important alternative to consider in this discussion, because 1) to my knowledge they are not about to be part of any Linux distribution and 2) they don't intend to support as many platforms, particularly some that Drupal supports (Windows, Solaris). I totally like Percona and they deserve all the support and encouragement they can get (the most important improvements in MariaDB 5.1 also come via them), but I'm just sharing information here.

* Should also point out that MySQL 5.5 is a beta, and not found in any Linux distro's or anything. As I said earlier, it is Oracle policy not to comment on when it may be released, if at all (like MySQL 5.2, 6.0 and most recently 5.4 were never released, as can happen in SW development, so it is arguably a wise policy).

* It is correct that since MySQL documentation is not open source, the forks have to start from scratch without using MySQL's documentation. In MariaDB I know for a fact that all new features have been documented, so MySQL proprietary manual + the separate MariaDB manual is a complete documentation. Percona seems to have a goal of this level of documentation, and each time I've looked something up I've found what I needed. In MariaDB we are aiming to eventually produce a full replacement manual, this is of course a lot of work but has started already (to be published soon).

The MariaDB manual is double licensed GFDL + CC BY-SA. See http://askmonty.org/wiki/Askmonty.org:Copyrights
This is marked on every page of the manual, I have no idea why you would think there is anything unclear.
(It is correct that the man pages / --help output is GPL and adapted from MySQL.)

* I'm not quite sure how sheeri's comment about the ODBA is relevant to this discussion, but "kickbacks" is more commonly known as "commission" in sales jargon. This has nothing to do with the legal governance of the trademark that I mentioned earlier. For example, user groups or other non-profits can be and hopefully will become members of the ODBA.

* MySQL is of course open source (hence the existence of forks) but only Oracle can ever release a product (aka binaries) called "MySQL" (hence this discussion of what name(s) to use).

Finally, after reading both of your comments: did either of you look at the most recent patch? Personally my worst experience ever wrt Drupal was when I submitted a patch and people commented on it without even reading it (fully). I really hope you did.

(Hmm... seems like correcting errors takes up more bandwidth than making them. I feel like I should apologize to everyone for this unnecessary turn in the discussion. We're sorry and believe it or not we are all friends.)

+ - MySQL 5.0.15 (or greater) (http://www.mysql.com/).

Please, recommend a more recent version. MySQL 5.0.15 may be enough to work with Drupal, but it is full of bugs. Any version earlier than 5.0.80 should be considered obsolete. And, most important, MySQL 5.0.xx is now in extended support. Meaning that it will only receive security patches, not new development.
Similarly, for 5.1, the minimal version should be 5.1.30 (the first GA).
The above, if someone must use existing installations of MySQL. If you can choose, you should go for the latest 5.1 releases (5.1.47 and later have a new InnoDB plugin recommended for production. http://datacharmer.blogspot.com/2010/06/performance-gain-of-mysql-51-inn...).

1) This is not the place to debate MySQL vs. MariaDB development practices. Let's please keep those elsewhere.

2) datacharmer: This also isn't the right thread to discuss the MySQL required version. :-) If you really want to discuss that please open a new issue. However, we're constrained primarily by what is installed out in the wild. We cannot get away with requiring a newer version of MySQL than ships in current versions of major distributions, and possibly the last version. We can recommend, but not require. We've also run into lots of issues with various versions of 5.1 in the past, too, so we'd have to be careful with that.

Does anyone have a problem with the actual content of the patch in #58? If you are not discussing that patch, and have read that patch, please refrain from commenting so that we don't get off topic. Thanks.

OK, I count now chx and crell and I as +1 on the patch in #58. I haven't seen anyone protesting. At this point, I think it's also fairly non-controversial as it's worded. Let's set to RTBC and see what Dries and/or webchick has to say (or if they want more input).

I'm OK with this. Committed to CVS HEAD. Thanks.

Wrong queue. I'm not sure what the Handbook project is?

Oh. Looking at the breadcrumb trail on this issue (before the change I'm just about to make), it's aparently a theme called "Handbook". :)

I've updated http://drupal.org/requirements -- review?

@hingo -- The Oracle ACE Director designation obligates us to *continue* to speak in the community about Oracle products, which now include MySQL, but there is no obligation to speak positively about it. In fact, they encourage us to be open and honest in reviews of MySQL products. I did not mention it because it is irrelevant and does not affect anything, just like the fact that I'm a knitter, I worked for a db consulting company doing MySQL, Oracle and SQL Server database management, or the fact that I'm female have absolutely no bearing on my opinion in this matter.

And yes, I looked at the patch, I was commenting on *earlier* statements. I am not disagreeing with the patch.

Percona maintains that their build is a build on top of MySQL, and that they are not interested in maintaining MySQL (ie, if the source ever does become closed, which is unlikely). Perhaps their opinion will change, but I believe them when they say that.

I believe the Percona build should also be documented even though it doesn't support as many platforms. Remember that most people are going to use MySQL, period. A limited subset might try MariaDB or Percona. Percona is verified as more performant than MySQL 5.1. Nobody who seriously wants performance should be using Drupal and/or a database on Windows anyway.

Note the title: "Document that MariaDB and Percona build work, too". Percona build works, MariaDB works, MySQL works. Maybe for different operating systems, but if you're going to put MariaDB in there you ought to put Percona in there too, since it's a stable, proven to be compatible and proven to give performance enhancement.

To keep it short -- please add documentation that Percona build works, too. (I do not work for Percona, I do not get any kickbacks/commissions, etc. I'm just trying to be fair here.)

We have tested MariaDB extensively (see above). I don't believe we have tested Percona extensively, and until we do, I think leaving the text as it is would be best.

It is irrelevant to cite Percona builds, because all those patches are in MariaDB, and the teams at Percona work in close cooperation with MariaDB.

Percona has already stated that they are going to switch to just distributing MariaDB (see #17).

#54 That's great to see work starting to get MariaDB included in the Ubuntu Universe repositories.

The text looks great imo. If MariaDB picks up more traction then it'll already be in the docs before endusers start asking about it. Can't go wrong there. :-)

Sorry, the grammarian in me was having a fit. :-)

Just putting in a bit of feedback as a user. I like the change to the manual page, stating that MariaDB is an option. Not confusing in the least, with the prevalence of Googling these days. In fact, it educated me of its existence.

I think "MySQL, MariaDB, or equivalent" is not grammatically correct.

It should be "MySQL, MariaDB or equivalent".

No. We put a comma before "and" and "or" in a list, according to our Handbook style guidelines. Both comma and no comma are acceptable usage, depending on who you ask, and we use the comma.

Okay - cool.

It must be a British / US thing.

Long live the Oxford Comma! :-)

Hi Baron,

As a satisfied user of Percona as a drop-in replacement for mysql along with Pressflow as a drop-in replacement for Drupal, what really might be helpful here in the Drupal community would be a comparison chart. While this thread may not be the right place, a comparison chart between Percona / MariaDB / Mysql broken down by version (given that some of the differences appear to blur above version 5.5) might be helpful in documentation.

Aruna

I wou,ld love to see a comparison for maria vs. percona

+1

Baron-

There are quite a few comments in this thread. To your knowledge do we document besides this thread or have you heard from clients that we document anything giving any specifics about percona vs maria? (I personally do not think we should be in the business of a DB server comparisons)

-N