MySQL is a database. I don’t like it. It hurts my brain, not only because of its infamous help ‘no help installed; consult help’ messages. But then again I’ve never delved deep into database performance or use. I’ve always stuck with Postgres for ease of installation and configuration. So I don’t have enough baggage to engage in a technical criticism of it; just somehow I don’t like it.

It’s also controlled by a large corporation💔, which gives Team FUD ample opportunity to do what it does best. I sometimes do stuff with that large corporation💔, so my commenting here is open to plenty of accusations of bias. I’ll do so anyway.

It struck me that the recent Amarok beta announce💔 on the Dot got no less than three comment threads about the database. So it’s clearly a topic people care about, or are at least willing to get snippy about.

A lot of things in KDE need a database, in the sense of a persistent store of indexed tabular data. There’s plenty of implementation options to choose from, such as an XML store, SQLite (public domain), Postgres (BSD 1-clause) and MySQL (GPLv2+BSD.sleepycat). Which things need a database? The first two that come to mind are Amarok and Kontact; Kontact is the Personal Information Management suite and it uses the desktop-independent Akonadi server as a datastore. So I’ll write about Akonadi and Amarok (pure coincidence they’re early on alphabetically – maybe “A” is the new “K”?). There’s more, I’m sure, but I can’t be arsed right now to look them up.

When you’ve got a lot of independently developed efforts that need a particular piece of technology – a database – then coordination becomes desirable. Just desirable, not mandatory. Coordination ensures that there’s less suplication of effort (in development) and less resources used (at runtime) because of the effect of sharing. Ideally you would want different efforts (which nonetheless fall within the realm of the K Desktop Environment) independently say “Foo is the right technology for us,” based on a combination of technical merits and coordination effects. Then you get the right technology, shared between efforts.

At this point, both Akonadi💔 and Amarok💔 have picked MySQL. I consider both projects (Amarok is a highly visible user application, while Akonadi is the under-the-hood data-store for PIM data and other stuff) essential parts of a complete desktop – any desktop, as Akonadi is desktop-independent and Amarok is an application that uses the KDE libraries. I am very glad that there is a coordination effect here. Switching either one of them from one implementation of database technology to another (i.e. saying that the shared Foo isn’t the right choice but that Bar is) comes with a cost: you lose the shared Foo and the coordination advantages that come from it. Another cost of switching implementations or supporting multiple implementations is maintainence. Yes, yes, “KDE is all about pluggable architectures” but at this point I don’t think that abstracting and wrappering all relational databases is a big win for us as a project, so there’s no Tabulon (RDBMS counterpart to Phonon) in the works. The wins elsewhere really need to offset these costs.

In a way this is similar to what drives the development of the KDE libraries (the technology underlying the desktop, workspace and the applications). If more than one application needs a particular bit of functionality, effort is put into finding commonalities and coordinating some development so that we get shared code, suitable for the current uses and hopefully for future use as well. Then it hangs on until the next major KDE release, so there is a strong incentive to do it right.

So anyway, to return to the topic: a KDE desktop will necessarily use and run the Free Software MySQL database (either embedded or as a server, I’m not sure of that, and they might even run different flavors) and that’s because that is the choice made by several groups of KDE developers based on what it costs them in terms of engineering effort. Maybe it’s not all the same flavor, but at least everyone agrees on the brand of Kool-Aid (so to speak, as Kool-Aid is a brand, not to be confused with Tang). I might not like it from a Postgres-user point of view but I can understand that converging on a shared technology has advantages that can outweigh my personal preference.

[[ PS. There’s partial patches to let Akonadi use Postgres; if the same is done for Amarok then my “coordination” argument can be used too to enable both databases. That’s a matter, probably, of finding maintainers for all the bits. ]]

[[ PPS. For some more Amarok comments related to the playlist, not the database, read Cláudio Pinheiro’s blog. Props to him; I toast him with a paper-cup-melting quantity of cachaca. ]]

Broken links marked with a 💔. The “large corporation” is Sun Microsystems, which was later consumed by Oracle.