Main Content

The future of MySQL

Archive - Originally posted on "The Horse's Mouth" - 2010-01-03 11:27:32 - Graham Ellis

MySQL has grown from a very neat little open source database 10 years ago into a very powerful and widespread database that's not always fully open source any longer today. The MySQL company was bought out by Sun a couple of years back (January 2008), and in turn Oracle are now buying Sun. This deal has taken a while to go through, and the delaying issues are said to be related to MySQL. If Oracle end up owning both their own database and MySQL, they will have something approaching a monopoly on databases, and that's probably bad news. See the blog of Monty Widenius, the father of MySQL where he points a gloomy picture of what would happen if the deal went through without checks and balances being applied. Monty foresees the open source branch being encouraged to wither and die, with users being offered an alternative / upgrade into Oracle's commercial products.

Quite apart from the MySQL training we provide, we make a lot of use ourselves of open source MySQL databases - in this web site and elsewhere - and like hundreds and thousands of small companies, the future of MySQL, the code that uses it and (especially) the data we've invested so heavily into storing under MySQL must be a serious concern for the future. Do we want to go commercial and buy licenses from Oracle? Or do we want to look for some other route?

Monty is encouraging users (via his blog) to contact the EU and let them know their views - I'll let you follow the link rather than reproduce all the details here. Please do follow up on this, folks; I am filled with profound misgivings about any one company ending up with a near monopoly on database storage ... it goes further that just a monoply on programs - your investment in data is probably worth far more than your code, and you don't want to have to pay Oracle (or any other single-source supplier) in the future to access / update it.



So ... where will MySQL be in 10 more years time? I don't know. But I do know that I'll want to access and update information that I have stored in my MySQL tables today, and data that I continue to enter every time I write a blog, every time a course is booked, every time I upload an image to my website. What steps should I take to ensure an easy and low cost path forward with this data, irrespective of where MySQL goes?

Here are my thoughts ...

1. Keep the database structures clean, normalised and vanilla.
2. Write code that uses as standard a subset of SQL as is possible.
3. Keep that code that calls the MySQL libraries within a database independent wrapper.

At this stage, those three elements are "hedging bets" rather than actively moving away from MySQL - they're just like investing in an insurance policy in case you need to cash in.

Monty's blog looks at alternatives such as a MySQL fork and PostgreSQL, but he doesn't see either as being a longer term solution. I'm going to offer you a further thought ...

I've been impressed in the last year or two by the growth of Lua. It's a great programming language which is perhaps just a twentieth of the size of Perl or Python .. yet for 80% of the uses of Perl or Python, it'll do pretty well. And so I look at the grown MySQL - release 5.x - and I think "MySQL 3.23.58 could have done almost that". For the small and medium size applications, there is a strong case for a back to basics database engine, and I would not be surprised to find something coming along.

Have you seen SQLite? It's in the public domain and already used heavily - VERY heavily - in lots of places. However, its model is serverless which could/should/would be expected to lead to data sharing and concurrency issues. But I note on the SQLite web page ... "Most SQL database engines are client/server based. Of those that are serverless, SQLite is the only one known to this author that allows multiple applications to access the same database at the same time.".

SQLite isn't necessarily the answer for the future ... but it may be pointing an interesting way forward - it may be a pathfinder for us. And (making myself thoroughly unpopular with the SQlite folks, perhaps), I see no reason why a server layer couldn't be written on top to allow it to be addressed via a TCP/IP port ...