MySQL – is this database fit for the Enterprise?
Part 2: Carving a niche
MySQL has recently appeared as an Enterprise edition. We have already looked at whether MySQL (the company) is enterprise ready, but we can also ask whether the product itself is suitable for enterprise use.
Some Reg Dev readers clearly have strong views about this already.
First up, remember that Enterprises come in all kinds of shapes and sizes. In the UK, 58.7 per cent of employed people (2005 figures) work for what we Brits call SMEs (Small and Medium sized Enterprises). The US has different definitions (see the SBA site).
Irrespective of the exact definition, MySQL can, quite clearly, compete effectively in the small enterprise space – which means it can already service nearly 60 per cent of the working population.
As an example, I talked to John Dyson, the IT director at First B2B. This is a new technology company that essentially manages messaging between other companies. Company A needs to send a message in CSV format to company B which needs it in EDI. First B2B receives the message, converts it to XML, stores it, and then forwards it in the correct format.
First B2B has a database of 24GB which runs on a four processor box with 2 GB of RAM. In the past, it used Progress as its database, but has now switched to MySQL and is very happy with the result.
Dyson said: "The support is excellent; indeed it is the best support I have ever known. The guys on the support desk are very quick and very knowledgeable."
He is also a major fan of MySQL's Monitoring and Advisory service: "It doesn't just highlight the problem, it will supply methods of how to fix it. It has made a significant improvement in the performance of some of our slower queries."
OK, so small enterprises can use MySQL very effectively. What about large ones?
Well, the classic way to answer that question is to quote a customer list. MySQL has a list that is long and distinguished, which is fine, but you have to bear in mind that it is just a list of the enterprises that use MySQL somewhere. It is not a list of the enterprises that use MySQL exclusively. It is certainly not a list of large enterprises that formerly used Oracle, took a look at MySQL, found it was great, threw Oracle out the door, replaced all of their Oracle installations with MySQL, saved quadrillions of dollars per year, and lived happily ever after.
The real picture is that many large enterprises that still rely on traditional database engines (such as Oracle, DB2 – and even SQL Server) to run their mission critical systems, are starting to try out MySQL. They use it for small applications, at the departmental level, for the newer web-based applications – in other words, in all sorts of innovative ways that are well suited to MySQL's particular strengths. But they are not yet using it for the "traditional" enterprise database application workloads.
How can I be so sure of this? Because I'm quoting Steve Curry, the director of corporate communications at MySQL who really ought to know:
"I think we'll all agree that MySQL is not a 'traditional' enterprise database - we never have been and aren't trying to suddenly become one now.
"We don't compete head-to-head against Oracle, DB2, Teradata, etc. If users are looking to build that type of higher-end data warehouse/OLTP/client-server application, then they've probably selected one of the traditional vendors or one of the open-source alternatives that are trying to directly emulate them. That's just not us - we're carving out new, different ground that is not based on replacing existing applications but creating new complementary online ones."
So, am I saying that MySQL is not, and never will be, a traditional, mission-critical, enterprise database engine? No, certainly not. What MySQL (the company) is doing is very, very smart. It has done a great job of establishing the product in a niche market which includes SMEs and departmental use in large enterprises. With the new tools and support options, it has laid the foundations which will allow for further expansion into the enterprise. What it will now do is further develop the product and wait for further adoption.
Curry said: "What we believe is that today's web technologies like LAMP, AJAX and Ruby will become tomorrow's enterprise infrastructure. So, we have come out with a 'MySQL Enterprise' subscription to help those companies who may need some help/support/risk management instead of relying on their own MySQL DIY hacker/guru types."
Although neither company will thank me for the comparison, this reminds me of the route that SQL Server started upon 10 years ago.
Remember SQL Server 6.5? It was a dog. When 7.0 arrived, it was a revelation – a completely different product; but its reputation preceded it, barking all the while. So Microsoft bundled all manner of excellent analysis tools in the box. Many large enterprises started to deploy SQL Server, not for the engine, but for the analytical capabilities. SQL Server got its foot in the enterprise door. After 10 years that foot has booted out innumerable Oracle installations and SQL Server is now one of the big three.
MySQL is starting out along the same track. I don't think that it's currently "enterprise ready" in the sense of being a direct replacement, throughout an organisation, for one of the big three. But it is ready for deployment in small to medium sized enterprises and at the departmental level in large enterprises. It already has that crucial foot in the door and this new edition gives it some kicking potential. ®
MySQL Enterprise requires fewer DBAs
According to an analyst firm, Forrester Research, MySQL Enterprise reduces the DBA requirements.
Popular but poor
You have a business to run and you have a choice to make - to buy a bicycle for small change (MySQL) or to acquire a heavy-duty truck for free (PostgreSQL).
A MySQL campaign o
Personally I feel much better when a mission critical system is built around PostgreSQL database. I think PostgreSQL is already ready for Enterprise -- it has support available from companies like Fujitsu or Sun and also the EnterpriseDB which aims at Oracle compatibility.
As for MySQL... it has its drawbacks. You have to double check all the features work as expected (as you have learned using DB2 or Oracle), otherwise you may be seriousley bitten,
as many of its users have. And get ready for some hacking like reimplementing sequences yourself because AUTO_INCREMENT is not exactly the thing you need, learning to define FOREIGN KEY constraints the right way, so they are not considered just comments by the database or keeping in mind that by default comparisons are case insensitive (unless declared binary/case sensitive locale). These are the things which make some people claim MySQL not ACID compilant. If you intend to use MySQL where data is very valuable, make sure you hire people who really KNOW this specific engine.
Being bitten too many a time I have happily converted to PostgreSQL (together with Oracle).