Let me preface this by saying this is my personal opinion and does not express any official MySQL standpoint.
While certainly not the first to issue the statement, “MySQL Is Not a Real Database”, yesterday Dave Dargo, advisor to Ingres, blogged about his thoughts on why indeed MySQL is not a real database. Let me present my thoughts about this now-long-tired strain of thought.
Dave, while acknowledging that MySQL is “one of the most successful database systems out there”, states the he holds self-evident that “MySQL is not a real database”. I think Dave, and thousands of other professionals in our industry, are missing the point: MySQL isn’t trying to conform to some decades-old definition of what is a “real” database. Why? Because we aren’t stuck in the past; we’re forging ahead with technology, concepts, and application use cases that focus on the future, not some old mainframe, centralized behemoth IT structure.
A Realistic Database
If being a “real” database means the following, I don’t want MySQL to be a real database.
- Proprietary and closed source
- Inflexible architecture incapable of acknowledging the fact that there is no single definition of data
- Follows a theory that all data are equal — yeah, I said it. All data aren’t equal. Get over it.
- Requires expensive, multiple DBAs to operate a single database installation
- Requires extensive, costly training to run effectively
- Cannot scale OUT, and instead only UP
If that’s a real database — and I do think this is the status quo for 90% of the systems Dave speaks of — I want no part of it. I’d much prefer MySQL be a realistic database. What is a realistic database? It’s a database that encourages the theory that there isn’t a single, one true way of doing things. It’s a database that encourages the development of applications (you know, the things the customer and the user actually see and use), and not database code. It’s a database that is designed for commodity hardware and scales in an outward fashion in a model that more closely matches the incremental budgeting needs of modern, nimble and forward-thinking companies, not monolithic behemoths with rigid departmental and structural silo organizations.
Sure, Follow the Past Techno-Concepts… Right to the IT Grave
Dave points out on his blog that Oracle is charging exhorbitant rates for a “database-centric” technology when customers are using “application-centric” thinking. That is, customers are developing applications, and the database is secondary to that application development. Well, heck yeah! That trend has been strengthening for the past decade since MySQL and SQLite came on the scene and decided, unlike other RDBM systems, to get out of the way of the developer. MySQL achieved ubiquity because it didn’t require the user to have 5 years of training to use the darn thing. It just worked.
Other RDBM systems have to start realizing that the user and the developer are the ones who now are exercising power. Why? Because technology like MySQL, like ODBC and the ease of use of products like Microsoft Access, and the proliferation of ease-to-use tools like the Wiki are changing the game in which products like PostgreSQL and Oracle have long relied on having a static playing field.
Why I Simply Don’t Care About The Flame Wars Anymore
For as long as I can remember, there have been die-hard fanatics of every relational or object database system, many of which seem to have inordinate amounts of free time to camp out of Slashdot and bemoan the lack of features in one system or another.
I have realized recently that these people, who argue that MySQL is an inferior product because it lacks feature XYZ, are in the same old time warp that Dave is. These folks say, “until MySQL supports some feature that PostgreSQL, Oracle, MSSQL, DB2, etc has supported for eleventy billion years, it won’t be a real database” (or, my favorite, “it will continue to be a toy database”). Dave is saying the same thing, but from a pricing comparison perspective: “You need a real database. Why pay Oracle top dollar for it? (Buy Ingres instead…)”.
Features are great. But unless they truly help application developers more rapidly and efficiently construct scalable web applications, those features are simply carrots dangled in front of the Oracle DBA crew in order to make them feel more comfortable moving away from a product they are used to using. Heck, I would think it would be terrifying for an Oracle DBA to be confronted with a white paper or internal study showing that some application could be rewritten to use MySQL and their jobs would be at stake because there would no longer be a need for so many DBAs just to keep an application running. This pitch is pure and plain FUD, playing to the fears of job loss.
It is an unfortunate trend for DBAs, but a trend that I see is strengthening: the role of the DBA will, over the next few decades, be reduced or possibly eliminated, and the applications and database developer will take over that functionality. You can already see this happening. If you go to OracleWorld and ask attendees at a session whether they are a DBA or a developer, who likely will get a distinct line between those who develop, and those who administer. Not so with MySQL. At SCALE5X a few weeks ago, there were more attendees in my seminar that answered they did both development and DBA work than there were any distinct developers or DBAs. It’s a changing role, and I think MySQL’s ease of use and maintenance is the largest reason for this trend.
OK, nuf ranting…