If you want a serious database (for something a little more involved than just storing basic data for a simple web app) don't overlook PostgreSQL (www.postgresql.org).

PostgreSQL is a much more serious database which has had full ACID compliant transactions, triggers/stored procedures, constraints, foreign keys... all the "enterprise class" features which enterprise users want.

It also doesn't mangle your data to fit, unlike MySQL.

Like MySQL, it's free and open-source, although you can go and pay for commercial support if you feel you need it.

BTW No offence intended to MySQL, it's a great project, a very fast database server which powers so many websites and projects, but I wouldn't use it for something where data integrity is critical.

Cheers

Dave P

(no connection with PostgreSQL other than being a happy user)

I'm sorry to say that Mark Whitehorn's article about MySQL fails to live up to the high standards that I expect from The Register. There are at least two inaccurate assertions.

"It will never make serious inroads into the enterprise"

I imagine that companies such as Sabre, Suzuki, Sony, T Systems, Lycos, Cox Communications and Dell would be surprised to discover that they are not operating at "enterprise" level because they use MySQL for key database-driven applications.

"MySQL didn’t even support transactions until recently"

MySQL has included the InnoDB transactional database engine for many years, as part of its standard free database server product.

Not to take away the general thrust of the article, the statement that "It will never make serious inroads into the enterprise" is just plain wrong: Google; Yahoo!; NASA; TicketMaster; Linden Lab; Deutche Post; any number of federal, state & city agencies in the US & Europe; UNICEF & UN; many media companies ... the list goes on: http://www.mysql.com/customers/

This is a really poor article. I am surprise it made it through to the site!

"Happily, deciding into which camp you fall is easy. You're a MySQL fan if you:

* can pronounce LINUX with authority

* prefer a command line to a GUI

* have a copy of ‘The Cathedral and the Bazaar’

* don’t read manuals

* are so productive that you can wear a t shirt at work

* hate Microsoft

You are not a MySQL fan if you actively choose to wear a suit and believe that bug counts are inversely proportional to price."

What on earth is this? This is total and utter nonsense, was the author drunk at the time?

Please write with more intelligence next time.

Dominic

Thank you for taking the trouble to post comments.

Yes, I agree. PostgreSQL is also a fun database engine.

MySQL’s record so far in the Enterprise market.

It is perfectly true that MySQL has a long list of customers and I’m delighted. However not even MySQL would claim that all of these companies have replaced their mission-critical systems with MySQL. Many of them are using MySQL as a very cost-effective database engine for non-critical systems whilst still running more traditional engines for their core systems.

In addition, the world is a very big place with a great number of companies and the customer list of a product like DB2 is immense in comparison. In enterprise terms, MySQL is still way behind the big three.

For example, Gartner ranked the engines like this for market share in 2005:

Oracle 48.6%

IBM 22.0%

Microsoft 15.0%

Teradata 3.2%

Sybase 2.9%

Other vendors 8.2%

MySQL doesn’t even appear. Now, it is quite true that Gartner essentially uses revenue (of one kind or another) and that measure discriminates (until now) against products like MySQL. Nevertheless, it is clear that MySQL has not, so far, come anywhere close to the penetration of the other engines. Indeed, part of the reason for the change in sales model that the article outlines is to try and improve the enterprise sales of the product.

Transaction support.

Transactions are clearly a topic of some interest to Reg. Dev. readers:

http://www.regdeveloper.co.uk/2006/12/22/access_not_relational_myth/comments/

As discussed there, deciding exactly when an engine provides full support for transactions is not easy. However MySQL, the company, announced in a press release dated September 23, 2002 that:

“the MySQL database now provides full support for transactions to enable the development of e-commerce and other robust, business-critical applications. The standard version of the MySQL database now includes a high-performance transactional storage engine with crash recovery and other capabilities that will significantly extend MySQL's role in the enterprise database market.”

So, let’s take that date as correct. It is just over 4 years ago. I have no doubt that this seems like a long time ago if, for example, you have only been using MySQL for three years. Indeed, it must then seem as if the product has always supported transactions. However, in transactional terms, this is still recent history.

It is worth remembering that the concept of a transaction didn’t pop into being one day, fully formed. It took a great deal of effort to develop over many years and Jim Gray did much of the fundamental work. In 1975, along with Chamberlin and Traiger he published “Views, Authorization and Locking in a Relational Database System”. This was followed by a long series of papers including the classic “Transactions and Consistency in Distributed Database Systems” and “A Transaction Model”, both in 1980.

Relational engines were being developed during this time and they started to embrace the notion of transactions and implement Gray’s ideas. For example transactions, at least in terms of commit and rollback, first appeared in Oracle version 3 (1980). Subsequently, as our understanding of transactions further improved, Oracle improved the support in future versions.

Seen within this broader context of enterprise level database engines supporting transactions since 1980, MySQL’s introduction of support in 2003 has to be seen as relatively recent.

PostgreSQL is sometimes called the "open-source Oracle" because it matches up pretty well with the big boys in terms of features, stability, and speed.

Like MySQL, PostgreSQL is free software. The two are often compared for that reason. Thing is, the comparison often goes something like this: MySQL is faster than PostgreSQL! (When using the MyISAM table type, that is.) MySQL has most of the features of PostgreSQL! (When using the InnoDB table type, that is.)

People use that combination of arguments to make the conclusion that MySQL is both faster and feature-comparable to PostgreSQL. Problem is, using the fast table type, MySQL doesn't have some of the important features of PostgreSQL, and, conversely, using the more feature-rich table type, MySQL and PostgreSQL are equally as fast.

Whenever possible, I use PostgreSQL over MySQL on web apps, no matter how mission critical or not. I think the only thing the MySQL dudes are actually better at is marketing.

So what must the world's nicest database do to drum up some enterprise sales?

How about something along the lines of "built it and they will come?".

mySQL lacks enterprise class features and compares very poorly against today's commercial enterprise RDBMS products.

For what it's worth, I can tick yes to to 5 of the 6 points listed as to why one would be a mySQL fan. However.. horror of horrors.. I do read the manuals. I used it as reference material almost every single day.

I think that only idiots deem their kung fu skills being so leet that they need no manuals. (opinion based from regularly assisting those who do not RTFM on Usenet and web forums for more than a decade)

Perhaps that explains some of the fan-base of mySQL?

The enterprise database is more than a mere bit bucket and black box. It must scale. It must perform. It must protect data integrity. It must provide redundancy. It must provide security, both ito access to data and securing data.

We did try mySQL in the very early start of an enterprise project. But we pretty soon gave up on it. Amongst numerous problems were that is was not able to handle the 1000+ inserts/second of numerous Perl processes. Not too mention that its share-nothing cluster approach was sorely missing the point on providing a fully scalable and redundant massive parallel processing architecture.

Built it. Give mySQL the features that make in on par with Oracle's transaction isolation levels, multi-version concurrency control, scalability, and redundancy. Add features like parallel query, table partitioning, real application clusters, PL/SQL.. to mention just a few. And only then can we in the enterprise RDBMS environment consider it as a worthy candidate to consider.

Terrabyte databases are common in the enterprise. Billion row tables are common in the enterprise. Running 1000's of SQLs per second is common in the enterprise.

mySQL as an enterprise RDBMS? Currently it is the Little Database that cannot, as far as enterprise RDBMS is concerned.

This article is about the new version of MySQL and the opportunities/challenges that it poses for the company. It is not about the suitability (or otherwise) of the database engine for the enterprise market. Just because many people find the free version great for the purposes to which has been traditionally been put doesn’t mean that it can withstand the white heat of the enterprise environment. Billy Verreynne’s experience suggests to him that it can’t; what are your experiences?

We intend to follow up this article with another that does examine MySQL’s enterprise capabilities. If you have an experience that you are happy to share with the World, feel free to post it here or email it to me.

"We did try mySQL in the very early start of an enterprise project. But we pretty soon gave up on it. Amongst numerous problems were that is was not able to handle the 1000+ inserts/second of numerous Perl processes"

Sounds like you didn't configure it very well - apps like Flickr handle over 20k+ transactions/sec. They also quote 4bn queries/day.

http://mysqldba.blogspot.com/2006/08/unorthodox-approach-to-database-design.html

J