January 24, 2008

14 reasons not to use MySQL or other mid-range database management systems

I may argue for the use of open source and other mid-range database management systems, but a lot of industry sentiment remains on the other side. Vendors of high-end RDBMS naturally advocate enterprise-wide single-vendor adoption. Many CIOs and industry analysts, overwhelmed by product proliferation, think that’s a neat idea as well.

And in fairness, they’re not entirely wrong. Here are 14 reasons for using high-end relational database management systems, even on applications for which mid-range DBMS would suffice.

  1. Many enterprises get quantity discounts. License and in some case even maintenance fees may not be bad at all.
  2. Who cares if the system contains code for features you don’t need? Hardware is really cheap these days.
  3. If you already have DBAs on staff, how much work is it to administer a few more small systems? Besides, an Oracle or SQL Server DBA has access to some pretty good remote tools, which let her administer many database servers at once.
  4. If you run a Windows-only shop, why not go Microsoft soup-to-nuts?
  5. SQL Server used to be a mid-range DBMS, and still plays that role in many Oracle and DB2 shops today.
  6. Early on, Microsoft did a great job of usability engineering on SQL Server administration tools.
  7. Largely in response to Microsoft competition, Oracle radically improved its own tools. For sufficiently simple databases, installation and administration really aren’t that hard in any of the high-end DBMS.
  8. Oracle, SQL Server, DB2, and Informix all offer cheap or free low-end editions, with good upwards compatibility. Those might happen to meet your deployment needs, now and in the future.
  9. If your application grows so quickly that you really do wind up needing a high-end database management system underneath, you won’t have to rewrite it.
  10. Most high-end database management systems have more robust datatype support than most mid-range DBMS, the PostgreSQL family of products excepted.
  11. Upstart mid-range database management systems have a variety of maturity issues. What are the most common kinds of error messages you see in a typical week? If you use the Web a lot, MySQL errors may be in the top three. Those memory buffers seem to fill to the choking point all too often.
  12. Individual features may also not be very mature yet. MySQL has long offered stable transactions and decent clustering, but not necessarily with the same storage engines (and not necessarily either in the most common configurations). And how is performance on relatively new features like declarative referential integrity, user-defined functions, or stored procedures?
  13. There are more and better third-party tools for popular high-end DBMS than there are for upstart mid-range database management systems.
  14. Nobody you know ever got fired for recommending a traditional, over-engineered computing platform.

On the whole, I think there should be a lot more use of mid-range database management systems than there is today. But the case isn’t entirely one-sided.

Comments

25 Responses to “14 reasons not to use MySQL or other mid-range database management systems”

  1. Monash Critic on January 24th, 2008 9:54 pm

    Why do you bother publishing your rubbish on Planet MySQL if you can only badmouthing MySQL?
    Why don’t you take a break?
    Relax.
    You are very, very, very narrow-minded. Take a vacation and think about that. Your billion dollar deals are still far away.

  2. Roland Bouman on January 24th, 2008 10:14 pm

    mm, I feel compelled to debunk this slander 😉

    #1
    “Many enterprises get quantity discounts. License and in some case even maintenance fees may not be bad at all.”

    You make it seem like this is an advantage! With MySQL, *everybody* gets a volume discount. We don’t care if you’re big or small, if you need many MySQL servers you simply pay *one single flat fee* to cover for support for *all you can eat*

    http://www.mysql.com/products/enterprise/unlimited.html

    #2
    “Who cares if the system contains code for features you don’t need? Hardware is really cheap these days.”

    This is not a reason to go for a high end database – merely something that might not hamper you in doing so. That said, it’s not that hard to argue why less is more. Take for example MS SQL’s xp_cmdshell (http://msdn2.microsoft.com/en-us/library/ms175046.aspx) which lets you run an arbitrary OS-level command. Well, if your app has a leak, an extra feature like this just allows a cracker more room to do damage. So it really pays off to be sure your database is exactly that – a database.

    #3
    “If you already have DBAs on staff, how much work is it to administer a few more small systems? Besides, an Oracle or SQL Server DBA has access to some pretty good remote tools, which let her administer many database servers at once.”

    I don’t see how this is an argument to buy into high end databases. First of all, if you run MySQL or any database that is anything worth to you, you need a DBA. Period. The “besides” is hilarious – what’s makes you think MySQL DBA’s do not have such tools? In many shops I’ve seen Oracle and MS SQL DBA’s use remote desktop or shell access to manage their db’s, in much the same way as many MySQL DBAs manage their DB’s. And, in addition MySQL Enterprise comes with an enterprise monitor which lets you manage and monitor many, many (hundreds) of MySQL instances remotely.

    http://www.mysql.com/products/enterprise/monitor.html

    You can even get it for trial:

    http://www.mysql.com/ent-trial-reg-2007/

    #4
    “If you run a Windows-only shop, why not go Microsoft soup-to-nuts?”

    heh, maybe because you want to rely on what you know will work – not on what you are promised that it will work. Sometime 😉 Seriously – the choice for MS vs non-MS is all about choice vs piece of mind. Nobody ever got fired for buying Microsoft, so many IT managers buy a site-wide all MS license to get some piece of mind. They get some assurances that because it’s MS everything is integrated and aligned and whatnot. But if you unpack the shiny boxes – that’s when you find out how incredibly compatible MS is with MS. Not.

    Contrast that to open source – not just MySQL. If it doesn’t work or you don’t like what you see: fine, grab a new. Try that with MS. Once people have bought into it, they feel compelled to make it work, why else did they spend all that money on it? We’re talking about a company that can’t even keep their frigging *browser* compatible between minor versions….seriously.

    #5
    “SQL Server used to be a mid-range DBMS, and still plays that role in many Oracle and DB2 shops today.”

    heh, this is hardly an argument. “Rain is wet, and still falls into many seas world-wide”. I mean, how can this be a reason not to go for MySQL or another open source database?

    #6
    “Early on, Microsoft did a great job of usability engineering on SQL Server administration tools.”

    I won’t contest that they did. But we are seeing it no being gradually replaced with more and more MS Visual Studio headaches. Is that what people really want?

    #7
    “Largely in response to Microsoft competition, Oracle radically improved its own tools. For sufficiently simple databases, installation and administration really aren’t that hard in any of the high-end DBMS.”

    gah…so how is this an argument for not choosing for MySQL? Seems like you should have titled your article “15 reasons why I like MS SQL – not 15 reasons why people should not choose MySQL”

    #8
    “Oracle, SQL Server, DB2, and Informix all offer cheap or free low-end editions, with good upwards compatibility. Those might happen to meet your deployment needs, now and in the future.”

    I won’t contest that the “express” editions are very useful development tools. But you must be joking when you are saying that these are serious deployment platforms. In fact, if you like these “Express” editions so much, you should be in favour of more MySQL, more postgres, more SQLite. Because those products are the sole reason that finally made the big vendors look for a way to make their overpriced offerings more appealing. Go rewind Tom Kytes Oracle XE announcement podcast – they started giving it away for free because they are basically forced to.

    #9
    “If your application grows so quickly that you really do wind up needing a high-end database management system underneath, you won’t have to rewrite it.”

    That’s a load of it. MySQL is all about scaling beyond the scale-up threshold. Don’t buy into bigger and more expensive – buy more and inexpensive.

    http://www.mysql.com/why-mysql/scaleout.html

    #10
    “Most high-end database management systems have more robust datatype support than most mid-range DBMS, the PostgreSQL family of products excepted.”

    Not sure what this means exactly – I guess this is not specific enough for me to recognize anything that has to do with MySQL.

    #11
    “Upstart mid-range database management systems have a variety of maturity issues. What are the most common kinds of error messages you see in a typical week? If you use the Web a lot, MySQL errors may be in the top three. Those memory buffers seem to fill to the choking point all too often.”

    So now MySQL is an upstart? heh…yeah, you’re right they’ve been around only 12 years. Personally the most common errors I see on the web are broken IE-specific pages but I guess that’s another story. (actually I’m curious if that’s in your top three as well) The most likely reason is that most dynamic websites are LAMP sites – MySQL is simply most ubiquitous. I don’t know how ever you were going to substantiate your “memory buffers” remark but most mysql errors I see on the web are “out of connections” – i.e. the site grew so hard they need to phase in another MySQL instance.

    #12
    “Individual features may also not be very mature yet. MySQL has long offered stable transactions and decent clustering, but not necessarily with the same storage engines (and not necessarily either in the most common configurations). And how is performance on relatively new features like declarative referential integrity, user-defined functions, or stored procedures?”

    Referential integrity relatively new…boy you must be an old fart to call something that’s been in there for more than 7 years “relatively new”. And what about the new features in Oracle and MS SQL? I don’t hear you complaining about the “relatively new” partitioning features in Oracle…

    #13
    “There are more and better third-party tools for popular high-end DBMS than there are for upstart mid-range database management systems.”

    And all of those are adding support for what database again? Right, MySQL, because at some point developers keen on those tools moved at some point to MyQL

    #14
    “Nobody you know ever got fired for recommending a traditional, over-engineered computing platform.”

    I think you hould make that your slogan.

    “On the whole, I think there should be a lot more use of mid-range database management systems than there is today. But the case isn’t entirely one-sided.”

    Well, you sure make a fine point out of making it look like a one sided issue.

  3. Marten Mickos on January 24th, 2008 10:15 pm

    Curt,

    Wow, that’s a long list! Thanks for posting it. I don’t see it as a negative thing – I see it as great fodder for us at MySQL as we improve our offering to compete even better than before with the other vendors. And I am proud to note that even despite those 14 items, MySQL continues to experience the fastest growth among enterprises.

    Marten

  4. Curt Monash on January 24th, 2008 10:19 pm

    Marten — Hi, thanks for posting, and congrats on the Sun deal!

    Roland and Anonymous Coward — please click through to the link at the top of the post, before you accuse me of being one-sided. This post was giving the OTHER side of what I usually write, for the most part. (The exceptions are where I think PostgeSQL and/or EnterpriseDB are ahead of MySQL in important ways.)

    Best,

    CAM

  5. Curt Monash on January 24th, 2008 10:27 pm

    Roland,

    If you want robust indexing of geographic or text data integrated into your DBMS, MySQL is not the product to use. Rather, the choices are Oracle, DB2, the Informix family, or the PostgreSQL family. MS-SQL also has workarounds for a couple of specific datatypes. That’s what I meant with that datatype point. Stay tuned for other posts explaining the point.

    As for your distinction between too many connections and memory pools — lack of memory is the reason for limits on connections. What’s more, my web host, who to my knowledge doesn’t handle any terribly busy sites, finds that MySQL will at times eat up all his RAM even so.

    One key measure of a robust DBMS — or for that matter website — is its ability to handle huge numbers of concurrent users.

    CAM

  6. Roland Bouman on January 25th, 2008 4:52 am

    From the comments on

    http://rpbouman.blogspot.com/2008/01/i-dont-do-rantsnormally.html

    “I also find it interesting that you’d so at odds with Marten Mickos’ comments in the same thread. Perhaps you could come back and share the reasons that you disagree with him?”

    Answered in the comments of that post on my blog.

  7. Gints Plivna on January 25th, 2008 11:33 am

    I’ve summarized criteria to choose new DB in my article here http://www.gplivna.eu/papers/choose_database.htm
    I think one of the main criteria choosing db for the next project should be everyone’s previous experience and existing labour resources. It is important to understand that each dbms is different and each new one needs a learning curve for your staff.
    So for one project probably it is worth to choose already known db, but if you are planning to use new db for many projects then investments most probably will be more profitable.
    Why we usually chose new db? Because we’d like to decrease spent $$. But of course these are not only license costs.
    There are at least some other direct costs and many indirect costs resulting probably in bigger spent $$ in longer future. I’m not somehow arguing against or pro any specific DBMS I’m just trying to formulate criteria everyone should keep in mind.

  8. A little bit of untruthiness about MySQL and Threads « MySQL-HA on January 25th, 2008 2:00 pm

    […] and Threads Posted in performance by mtaylor on the January 25, 2008 Curt Monash has an interesting post. As with everything on the web, I agree and disagree with various bits – which is one of the great […]

  9. Curt Monash on January 25th, 2008 5:30 pm

    Gints,

    That’s a nice start, especially for readers in your native language. But I can’t believe you have a list of DBMS that long without Netezza or EnterpriseDB on it. 😉 Or Progress OpenEdge, for that matter.

    In other news, I think you should submit the Latvian version to DMOZ, if you haven’t already.

    Best,

    CAM

  10. Why NOT to Use MySQL « Kevin Burton’s NEW FeedBlog on January 25th, 2008 6:12 pm

    […] January 25, 2008 in mysql A few MySQL-planeters linked to this article describing 14 reasons not to use MySQL. […]

  11. Frank on January 25th, 2008 6:51 pm

    My response as the MySQL guy for one of the heaviest trafficked website in the world is at
    http://mysqldatabaseadministration.blogspot.com/2008/01/mysql-and-threads-my-observation-and.html

  12. Gints Plivna on January 25th, 2008 6:53 pm

    Curt,
    To be frank I haven’t much experience with warehouses so these databases are new to me. However I’ll add them to my list 🙂
    Speaking about DMOZ – yea I’ve submitted it, but I have quite bad experience with my site – I submitted it once and then waited for more than a year, then submitted it again and after about a month it was listed. So probably there are some rules like site must exist for a while (year?) to be listed?

  13. Curt Monash on January 25th, 2008 6:58 pm

    Gints,

    Lest we go off-topic — for more DMOZ discussion please see http://www.texttechnologies.com/category/vendors/odp-and-dmoz/

    Best,

    CAM

  14. Ken Kaufman on January 25th, 2008 7:27 pm

    Good to see that religion is a live and well on both sides. Quite frankly it’s the narrow minds on both ends that get people fired. By taking up the cross and saying SQL, Oracle, DB2, or Mysql is the only way to go, you’ve closed your minds to a candy store of technology. In my group I stress the best technology for the job. Up in to last year our entire site ran on sql server for religious reasons. I led the charge to get MYSQL NDB in house because it made the most sense for an app we were writing. In the last year we’ve seen 8 DB’s come into place, 5 on sql server 3 on different mysql engines.

    All day long I here our open source guys tell me that mysql is better and the MS guys SQL Server is better. Truth is neither came make the claim across the board, it’s all dependant on what you’re trying to do. By the way one of our mysql installs went on Windows for a reporting application. Why did we choose windows, well in stress Windows ate Linux up.

  15. Daniel Weinreb on January 28th, 2008 3:42 pm

    At ITA Software, we switched from MySQL to Oracle for some of these same reasons:

    (1) There was reason to believe that MySQL had bugs when operated at very high capacity and high concurrency (this is for a large-scale highly-available OLTP application).

    (2) Oracle has more and better third-party tools.

    (3) Oracle has a bunch of high-end features that we felt we were going to need (and in fact, it turned out that we did). DataGuard is one of them.

    Some of our problems with MySQL may have been partially or entirely alleviated since we did our testing a few years ago. We have not gone back and re-tested.

    Note that none of the three points I mention above has much relevance to the case of running a basic “LAMP” web site. As was said earlier, what DBMS you used depends a lot on the job you are trying to solve.

    I’d also like to point out that Curt is not attacking MySQL, nor is he being an Oracle bigot. Rather, he is presenting the case for Oracle, which is quite different from actually advocating Oracle. I’d much rather hear from someone who understands both sides of a story than someone who is a unilateral advocate for a single approach.

    Just for the record, I’m not an Oracle bigot either. In fact, I was one of the co-founders of Object Design, so if anything I’m an object-oriented DBMS guy. However, Object Design’s product, while I am extremely proud of it, was not designed for OLTP and would not be suitable for what we’re doing at ITA Software.

  16. ricky on January 29th, 2008 4:36 am

    Great post, support.

    Why not using ORACLE~~

  17. Curt Monash on February 5th, 2008 1:37 am

    Hmm, it seems that I misunderstood my web hosting guy.

    MySQL isn’t his biggest concern, and when he did complain, it was just about a runaway query. And I presume MySQL has tools that allow automatic shutdown of runaway queries, although I don’t know whether they’re in the free version a web host can reasonably be expected to have. (If not, they should be.)

    That said, I still suspect that the lack of transaction integrity at sites like http://www.blogshares.com or http://www.namecheap.com (the latter of which REALLY hurt me yesterday) is related to weaknesses on the underlying DBMS. And at least in the case of the former, I’m sure that’s MySQL.

    CAM

  18. Database management system choices — mid-range-relational | DBMS2 -- DataBase Management System Services on June 26th, 2008 3:43 am

    […] The case against mid-range DBMS. This one generated a lot of flames. […]

  19. Infology.Ru » Blog Archive » 14 причин, по которым не следует использовать MySQL или другие СУБД среднего уровня on September 15th, 2008 4:50 pm

    […] Автор: Curt Monash Дата публикации оригинала: 2008-01-24 Перевод: Олег Кузьменко Источник: Блог Курта Монаша […]

  20. Tom on January 18th, 2010 11:21 pm

    What a pathetic waste of my time. The whole premise is since the negative is not so bad, why look for something better?

    This appears to be written by somebody selling the high-end, high-cost products.

    Ugh.

  21. Curt Monash on January 19th, 2010 12:03 pm

    Tom,

    You seem dissatisfied. Please contact us for a full refund of everything you paid us to read this free blog. 😉

  22. ITA Software and Needlebase | DBMS2 -- DataBase Management System Services on April 21st, 2010 12:55 pm

    […] ITA Software is an Oracle shop (see Dan Weinreb’s comment). […]

  23. What leading DBMS vendors don’t want you to realize | DBMS 2 : DataBase Management System Services on July 30th, 2013 2:37 pm

    […] For a contrary view, please see my follow-up post making the opposite case. Categories: Actian and Ingres, EnterpriseDB and Postgres Plus, IBM and DB2, Intersystems and […]

  24. agent smith on December 27th, 2017 2:49 am

    Lets look at these shall we?

    1. Many enterprises get quantity discounts. License and in some case even maintenance fees may not be bad at all.

    $$$ is not the only ‘cost’ there is also time.
    in the time it takes to install oracle, you can download mysql, install it, configure it and be deep into using it. So in terms of that, oracle is FAR more expensive. Oracle was quite surprised to find this out. Free oracle can be far more expensive than mysql.

    2. Who cares if the system contains code for features you don’t need? Hardware is really cheap these days.

    Hardware is cheap – but not free. All those features consume resources – even if you have a host of dbas, why use that resource for simple things that can by easily done by a mildly experienced user?
    lets try 30 instances of oracle v. 30 of mysql…

    >3 If you already have DBAs on staff, how much work is it to administer a few more small systems?

    Actually quite a bit. if you have to do a lot of handholding. If you have a system that has a very nice GUI that makes the admin very simple, you dont need a highly expierienced DBA.

    >Besides, an Oracle or SQL Server DBA has access to some pretty good remote tools, which let her administer many database servers at once.

    Gui Tools for Mysql is very handy. I’m administreing a Mysql server in the USA from the middle east. that remote.

    > 4 If you run a Windows-only shop, why not go Microsoft soup-to-nuts?

    its to expensive, its to complex, its to resource intensive for simple things…. thats for a start

    >SQL Server used to be a mid-range DBMS, and still plays that role in many Oracle and DB2 shops today.
    Early on, Microsoft did a great job of usability engineering on SQL Server administration tools.

    That was true a while ago. now.. arguable.
    check out the SQL Server pricing sheet.

    > Largely in response to Microsoft competition, Oracle radically improved its own tools. For sufficiently simple databases, installation and administration really aren’t that hard in any of the high-end DBMS.

    compared to MYSql – they are. let alone the time it takes and the resouces it take.

    > Oracle, SQL Server, DB2, and Informix all offer cheap or free low-end editions, with good upwards compatibility. Those might happen to meet your deployment needs, now and in the future.

    Yep they sure do.
    Look at what is installed – and what resources they use. there is a lot of complexity that is still there. light, still means you just loose the high end features and some artificial liminitatins.

    > If your application grows so quickly that you really do wind up needing a high-end database management system underneath, you won’t have to rewrite it.

    A half way deciently written data abstrat layer address this for you.

    > Most high-end database management systems have more robust datatype support than most mid-range DBMS, the PostgreSQL family of products excepted.

    I think oracle would take issue with that.
    You can get Oracle support for Mysql. what more support would you ever need?

    >Upstart mid-range database management systems have a variety of maturity issues. What are the most common kinds of error messages you see in a typical week? If you use the Web a lot, MySQL errors may be in the top three. Those memory buffers seem to fill to the choking point all too often.

    Thats the programmers issue, not the database.

    >Individual features may also not be very mature yet. MySQL has long offered stable transactions and decent clustering, but not necessarily with the same storage engines (and not necessarily either in the most common configurations). And how is performance on relatively new features like declarative referential integrity, user-defined functions, or stored procedures?

    This is why you use the proper tool for the Job.
    If you need a high end database system, you use one, if you dont, you dont.

    >There are more and better third-party tools for popular high-end DBMS than there are for upstart mid-range database management systems.

    You might want to do your research before you say things like that. Your credibility just vanished.
    Oracle owns Mysql, oracles tools work with mysql.

    > Nobody you know ever got fired for recommending a traditional, over-engineered computing platform.

    True, they just go demoted for not thinking the problem through and spending a lot of money they didnt have to.

    Mid range database systems exist for a reason. Use the proper tool for the job.

  25. Curt Monash on January 4th, 2018 6:51 pm

    Perhaps you didn’t notice that you were replying to a 10 year old post.

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.