Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

There Is No Reason At All To Use MySQL: MariaDB, MySQL Founder Michael Widenius 241

sfcrazy writes "In this exclusive interview MySQL founder Michael Widenius talks about the reasons of decline of MySQL, what Oracle is doing wrong and how MariaDB is fast replacing it. There are quite some interesting information in this interview. The take out of this interview is — '...there is no reason at all to use MySQL 5.5 instead of MariaDB 5.5. The same will be true for the next generation.'" Of course, he has an economic interest in getting people to use MariaDB. Hard to argue that Oracle isn't evil though.
This discussion has been archived. No new comments can be posted.

There Is No Reason At All To Use MySQL: MariaDB, MySQL Founder Michael Widenius

Comments Filter:
  • Postgres (Score:5, Informative)

    by Anonymous Brave Guy (457657) on Sunday May 05, 2013 @04:48PM (#43636791)

    ...there is no reason at all to use MySQL 5.5 instead of MariaDB 5.5

    Or Postgres, which is better than MySQL in numerous objective/technical ways and has been for years.

    • or sqlite (Score:5, Insightful)

      by mattdm (1931) on Sunday May 05, 2013 @04:57PM (#43636835) Homepage

      As a general rule of thumb, if you need something lightweight, SQLite is the way to go. If you need something more powerful or sophisticated than that, PostgreSQL.

      MySQL and spinoffs all occupy an uncomfortable middle ground. 99% of the small web sites which are built around MySQL don't need it.

      • MySQL and spinoffs all occupy an uncomfortable middle ground.

        Indeed. As well as SQLite, there is also a new generation of "NoSQL" databases that might serve some projects better. Any way you look at it, MySQL and MariaDB are stuck in a kind of limbo now. They could survive for years on nothing but inertia, but it's hard to see how they would be a good choice for any new project today.

        • by Nemyst (1383049)
          Many, many sites are still on low-cost shared hosting, where MySQL is often all there is. I'm not even sure you'll see a transition from MySQL to SkySQL or MariaDB anytime soon in that environment. It took them years to get to PHP5. MySQL is better than no SQL.
      • Re:or sqlite (Score:5, Insightful)

        by wmac1 (2478314) on Sunday May 05, 2013 @06:21PM (#43637213)

        Most people and websites do not agree with you. Ask facebook , wikipedia and thousands of others (if not millions).

        SQLite is not scalable. MySQL is lightweight and scalable.

        PostgreSQL has not been successful in penetrating cheap shared hosting providers. There is no web based tool comparable to phpMyAdmin and there are more reasons why PostgreSQL has not been successful despite its technical advantages.

      • by mveloso (325617) on Sunday May 05, 2013 @06:49PM (#43637353)

        The main reason to stay away from PostgreSQL is its toolset. Specifically, it's almost impossible to find a tool that allows you to analyze and tune it's performance. I say 'almost' because there may be one out there that I haven't found...but I've looked on and off for years, with no results.

        For mysql there's lots of tools, like jetprofiler. For oracle you can pay. For SQLite, well, who cares. For psql, it's (as one website put it) a black art. Do you really want that as your back end?

        • Thanks for that information. I have always wondered why PostgreSQL adoption isn't as high as MySQL.
        • by ducomputergeek (595742) on Sunday May 05, 2013 @08:20PM (#43637883)

          Have you not looked at the enterprise DB folks? A few years ago I was working on a project that started out using MySQL because MySQL was everywhere and initially it was for a single store. Then that became 50 and then 200 and we ran into some interesting problems with MySQL. Long story short, we ported the backend to PostgreSQL in a couple weeks and then ran for another three years processing tens of thousands of transactions a day without further hiccups from the database before we sold the company. The plan originally was to use PostgreSQL and then migrate to DB2 at some point once the revenue was coming in. Even when we reach that point PostgreSQL was handling everything we threw at it and we did hire Enterprise DB to come in and tune the database set up since we didn't have and couldn't afford to hire a DBA full-time at that point. IIRC they had a pretty decent toolset that we used there after, but it wasn't free as in beer or speech.

        • by greg1104 (461138) <gsmith@gregsmith.com> on Sunday May 05, 2013 @09:36PM (#43638307) Homepage

          The performance analysis tools for PostgreSQL are still rough, but they're coming out stronger now than ever before. The old slow query profiling approach is based on database log files, and the pgbadger [github.io] tool has gotten a lot of improvements in the last year to take the lead in that area. Some web app providers have added PostgreSQL data collection and visualization to the products recently, Datadog [datadoghq.com] is a good example, they even run Postgres internally.

          Last year's PostgreSQL 9.2 added a built-in query profiling feature via an improved pg_stat_statements [postgresql.org] module. That makes it relatively easy to see what queries are taking up time on the server, in a way that matches similar statements based on underlying their query plan. I wrote a sort of call to arms to suggest how the next generation of analysis tools can leverage that in Beyond Query Logging [2ndquadrant.com].

          You are correct that no one has really grabbed ahold of this area and put together a really easy to use tool set around it. All of the hard to construct pieces needed are in place now, and my list of goals for this year's 9.3 development includes pushing the tuning methodology outlined in my High Performance PostgreSQL 9.0 [amazon.com] book into some reference tool implementations. The idea that this is a "black art" is coming from consultants who want you to be intimidated. People who want to understand how things work can read my book, and then wander out to confidently build terabyte size databases. I talk with new people who have done just that every week now.

      • by AaronLS (1804210)

        "99% of the small web sites which are built around MySQL don't need it."

        Likely they are running on a virtual share, and as such as using the cheapest thing available that also supports the web apps they want to use.

        If the web app happened to support SQLite, it would still be a better choice to use the hosting provider's MySQL server since it is already configured for backups and likely runs on a separate piece of hardware from the virtual web server. Additionally they are probably using multiple tools, CMS

      • by jampola (1994582)
        This! Hell, using SQLite on most small web sites would be overkill and could quite easily grep text files all day long!
      • by frisket (149522)

        99% of the small web sites which are built around MySQL don't need it.

        I don't know about 99%, but there are certainly plenty of sites built by developers whose only knowledge of data storage is "database", and who therefore use one for everything, regardless.

      • by Rich0 (548339)

        As a general rule of thumb, if you need something lightweight, SQLite is the way to go. If you need something more powerful or sophisticated than that, PostgreSQL.>

        If I were ever writing something new I'd almost certainly use PostgreSQL instead of MySQL/MariaDB. The problem is that I end up using MySQL for almost everything anyway, because few FOSS projects actually support PostgreSQL If they did it would be a no-brainer.

    • by Trepidity (597)

      True, but that's a bigger change. MariaDB is a drop-in replacement for MySQL, because it is just a forked/renamed MySQL. To switch to Postgres typically requires some porting [postgresql.org].

    • In other news...Oracle is slated to release a new entry-level, free DB competitor named LarryDB.

    • Re: (Score:3, Interesting)

      by hairyfeet (841228)

      But you gotta give the dude credit as he managed to sell a product and keep it at the same time, walking away with the code, the customers AND a big fat check. How he managed to get those fools to buy it without making him sign a non compete I don't know but he pulled it off, hell you might as play the WB "sucker" music when you talk about Oracle and MySQL.

      So lets here it for old Monty, his balls are big and plentiful.

    • by Freultwah (739055)
      Good luck getting Wordpress to run with Postgres, at least without horrible hacks.
      • Re:Postgres (Score:5, Insightful)

        by Anonymous Brave Guy (457657) on Sunday May 05, 2013 @07:33PM (#43637609)

        In many ways, WordPress : CMS :: MySQL : Database.

        Both WordPress and MySQL are great success stories in terms of popularity and to some extent creating an ecosystem as a result. That doesn't make either of them particularly good technically. The way that WordPress was basically hard-coded to use a specific database is not any other database's fault. It's just another symptom of the questionable architectural decisions underlying it.

        • by i.r.id10t (595143)

          Of course, same can be said about Windows

        • by Freultwah (739055)
          I did not imply that it's in any way PostgreSQL's fault, just that some very popular software projects/products are (stupidly, methinks) hardcoded to use a specific database, which kind of limits one's options somewhat and hinders choice. You'd go with the better system, but you're stuck with whatever database system is forced upon you. WordPress is not the only culprit. DAViCal, for instance, only runs on top of PostgreSQL.
    • by gmuslera (3436)

      One reason to not go to postgres just yet is legacy code/apps/data that uses MySQL. If you put MariaDB instead of MySQL even the same binary data files should work, and you should get better performance and have room to do further improvements gradually (i.e. taking advantage of other storage engines) while all the rest keeps working.

      If you will to start from zero in a new project/code, or have margin to reestructure everything that is db specific to Postgres, then could be a better option (or not, meatwar

      • Please notice that I only advocated for Postgres on objective/technical grounds. There are always questions beyond pure technical merit when choosing which technologies to use, and things like non-standard behaviour/vendor lock-in are just as damaging in MySQL's case as they can be in any closed/proprietary system.

        I suppose in this case, the question is for how long MariaDB really will be a foolproof switch from MySQL, given the direction Oracle seem to be taking MySQL in these days. Your wetware and increm

    • It depends. MySQL's championship role has always been lightning-fast reads from tables that change rarely and don't need much in the way of concurrency protection. I believe it was also the first free database to have a concept of partitioning.

      The main problem with MySQL lately (past 5 years or so) has been the fact that it's really easy to get an inflated impression of its more "hardcore" abilities, and not discover until it's too late that MySQL's ability to handle things like failover, replication, parti

    • by goffster (1104287)

      except if there was not that silly concept of requiring periodic
      "vacuuming". This drives me up the freaking wall!

    • Or Postgres, which is better than MySQL in numerous objective/technical ways and has been for years.

      It's been a while since I've checked, but Postgres lacked native replication for many years, and when it finally got it, it was still pretty rough around the edges.

      I can make a mysql cluster that will have roughly zero downtime (obviously we can never say "zero" because that's impossible). As of the last time I checked, that was not possible with postgres. Upgrades meant downtime. Major version upgrades meant export/import of data.

      Anyway, I'm well aware of the technical deficiencies of MySQL. Like anything

  • Monty is a stooge (Score:5, Interesting)

    by Anonymous Coward on Sunday May 05, 2013 @04:48PM (#43636793)

    The Maria builds have not been particularly special, and its hard to take anything he says about MySQL seriously. So much doublespeak. Stop posting his rants as relevant or news. This is little more than an ad for his support/consulting org.

    • If you want the "free" version, there isn't a significant difference for 95% of users, agreed. However, MariaDB support is miles better and cheaper than Oracle's "Enterprise MySQL" support is. Also, calling Monty names is cheap and rather unfounded.
  • That's funny (Score:4, Insightful)

    by Anonymous Coward on Sunday May 05, 2013 @04:52PM (#43636803)

    It's also what Postres fans have been saying for years. Maybe they're right about other things?

    • by dutchwhizzman (817898) on Sunday May 05, 2013 @05:30PM (#43636993)
      Maybe Postgres is a better DB in a theoretical way. It could be that in a brand new design for an application, it will be better in practice as well. However, if you run existing code or use an "off the shelf" open source application, chances are, it will be tested and developed on MySQL/MariaDB and not on Postgres. Until the choice is just as easy to make as the choice for either MySQL or MariaDB, I doubt it's "better" for 90+% of all MariaDB/MySQL users. Those users have a choice for either something that works, or something that will need a lot of porting and testing done. It may seem small and insignificant to Postgres experts to do that, but to those 90+%, it ishttp://developers.slashdot.org/story/13/05/05/2050220/there-is-no-reason-at-all-to-use-mysql-mariadb-mysql-founder-michael-widenius?utm_source=rss1.0mainlinkanon&utm_medium=feed# most likely far beyond their capabilities, probably cost prohibitive and in a lot of cases just not an option at all.
      • by rnturn (11092) on Sunday May 05, 2013 @09:43PM (#43638339)

        ``However, if you run existing code or use an "off the shelf" open source application, chances are, it will be tested and developed on MySQL/MariaDB and not on Postgres.''

        That was my experience back when I was looking for web site software a few years ago. It's not so much that the "off the shelf" application hasn't been tested against PostgreSQL but it's almost certain that the developers only considered MySQL, taken advantage of non-standard SQL statements that are available in MySQL, and locked users into using only that database. I downloaded untold numbers of web site packages and found that most of them had used things like MySQL's "REPLACE" statement which meant they wouldn't be useful in my existing PostgreSQL environment without significant reworking. Standards, shmandards.

        Ideally, it'd be nice if more developers would write their application to use some of the database abstraction layers that are out there (PEAR, ADOdb, etc.). At least then users would be able to merely use the database they may already have installed.

  • Sign of OSS maturity (Score:5, Interesting)

    by Gothmolly (148874) on Sunday May 05, 2013 @04:59PM (#43636849)

    Most MySQL/MariaDB users wont care at all about this, because there are millions of them who are not Slashdot or Amazon or Facebook - this DB silently powers millions of Internet connected things, and it's just a given that it works, performs, has fit-for-purpose stability. It's a sign of how far OSS has come when people have the luxury of quibbling over WHICH free, capable DB they want to base their business model on.

    • It's a sign of how far OSS has come when people have the luxury of quibbling over WHICH free, capable DB they want to base their business model on.

      I'm not aware of any reliable numbers on how many copies of those databases are actually in use. Unfortunately, the only numbers that there's any confidence in is based on sales figures, which, given that open source doesn't sell software licenses at anything but, uhh, $0, isn't representational. Oh I know, I'm going to burn in the eternal fires of hell for saying open source isn't the greatest thing since sliced bread, but you did use the phrase "business model."

      If we're talking about a database that busin

      • Your burger is the MySQL protocol. Your toppings are the implementation: MySQL, MariaDB, Percona Server, or any other. You want fries with that? Percona offers support contracts for any MySQL variant.

        • Your burger is the MySQL protocol. Your toppings are the implementation: MySQL, MariaDB, Percona Server, or any other. You want fries with that? Percona offers support contracts for any MySQL variant.

          Error: Invalid object passed to function in line 1. Expected array of 'fact' but got 'handwave' instead.

          • I understand that you're in denial, but it will pass eventually.

          • I read your posts for awhile.

            Your enterprise is so backwards and has a fear of anything new. You praised IE 6 a few years ago because you didn't liek the new gui's of Firefox and IE 8 and Windows 7 at your place is still a slow process with people crying and kicking.

            Have you considered working in a more forward thinking environment where you are not a cost, and people are so scared of change? I work in such an environment now and since I am a contractor already have something else lined up.

    • by kestasjk (933987) *
      I'd say it's a big sign of a certain OSS developer's immaturity.
  • My reason is because there is no compelling reason right now for me to switch. Once it is in my next Ubuntu upgrade or my ISP switches to it then I'll do so as well.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I'm just in the process replacing our server and decided to give maria a try. Everything worked nicely, except when using SQL_CALC_FOUND_ROWS, ORDER BY is ignored in a subquery.

    • by Osgeld (1900440)

      there is no real reason when setting up a new database

      oh oricle (what do they know about databases) has mysql now, but a bunch of people who were not valuable enough to keep made a whole new database that has exactly jack shit track record

      thats fine for bobsdog.com, but I got shit to do and am too cheep to pay for MS

  • Especially since sqlite came about. For no-setup, small-size databases, you use that. For more features, if you need em, there's Postgress.
  • by FlyingGuy (989135) <(moc.liamg) (ta) (yuggniylf)> on Sunday May 05, 2013 @07:47PM (#43637697)

    98% of "web Programmers" wouldn't know a good database if it dragged them out of the parents basement and gave them a blow job.

    I would not recommend using Oracle to run a simple web site. It is complete over kill. I would not recommend using MySQL / Maria to run the VISA processing center either.

    99.9% of application builders do not even know the value of a good, much less great, DB engine and that is proven out time and time again when you look at their DB schema and all you see are tables. They all insist on doing EVERYTHING on the front end and never get , even when advised about, the amount of power that DB's like Oracle, PostGres, MS-SQL, DB2 and even MySQL have these days. One well written Stored Procedure ( Oracle Speak ). Package ( Oracle Speak ), function ( PostGres Speak ) or Procedure ( MySQL/ MS-SQL Speak ) can eliminate 1000's of lines of java, python, ruby, php ( pick your language ) front end code, and perform the function 1000x faster and more reliably.

    Every tool has its use. When you need massive scaleibility, up time in the 5 9's category and support RIGHT FUCKING NOW WITH AN ACTUAL ENGINEER when you dial the toll free number 24/7/365 you get the big dogs like Oracle,MS-SQL or DB2. If those factors are less important then you have other choices like Postgres ( they REALLY need to fix the TXID issue ) which is very powerful but lacks the kind of SLA's that you can get with Oracle / Microsoft. If just getting feedback from the support community is fine the MySQL / Maria are fine choices.

    I design VERY large databases that push DB's to their limits. Google had to design their own because nothing off the shelf or even from the FOOS community could handle their requirements but it takes a small army to deal with it and most companies don't have the resources or don't want to have that many people on their payroll.

    The bottom line is use the DB that fits your requirements, fits your budget and has the support organization around it so when you have a problem your requirements are met, and it really does not matter who you get it from. Don't be religious about it. ALL of these companies are trying to build the best product to serve their market and that is the bottom line.

    Michael Widenius is nothing but a little bitch. He sold his DB to sun for how much again? 1 BILLION dollars I think it was. Now shut the fuck up, go sit on your riches and do MariaDB if you want but stop bitching about what happened to MySQL because he YOU are the idiot who cashed in and sold out.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Big advice to anyone who ever gets the "bright" idea of trying to port a substantial application from MySQL to Oracle: don't. And if your boss tells you that you have to, start looking for a new job, because it's a fool's errand almost guaranteed to fail. Not even *Oracle* would ever recommend porting an app from MySQL to Oracle. The problem is that MySQL does well in many scenarios as long as you humor its quirks, but those quirks you've humored will come back and destroy your performance, or make it outri

      • That, and if you take a lot of business logic to DB level you REALLY have to know what you're doing, with triggers, constraints and other stuff creating race conditions and various other side effects and making the system harder to debug.

        Not that you shouldn't use stored procs, etc but you shouldn't become obsessed over it either.

        • by Rich0 (548339)

          Not that you shouldn't use stored procs, etc but you shouldn't become obsessed over it either.


          I'd go a step further and say simply never use stored procs. They really cement you into exactly one platform. If you write your code to be DB-agnostic then you're going to have a LOT more flexibility down the road. Oh, and that isn't just flexibility to change DB Vendors - even Oracle has been known to deprecate some of their stuff and if you relied on them that means a lot of rework. If you rely on ANSI SQL you can pretty-much guarantee that it will still work (if you use it right - like not assu

          • by snadrus (930168)

            I think a great advantage of SQLite is no stored procedures.
            I've seen stored procedures munge backup/restore operations and have all kinds of unintended consequences when a developer is over-aggressive with them.
            Then they're difficult to scale versus up-scaling front-ends that run the logic.

            As an ex-DB-Admin for ~100 developers, my rule was: no stored procedures.

  • by smash (1351) on Sunday May 05, 2013 @08:02PM (#43637783) Homepage Journal
    Postgresql is more feature complete, just as fast, and properly free software.
  • by Locke2005 (849178) on Sunday May 05, 2013 @08:05PM (#43637791)
    Oracle has a HUGE economic interest in making sure MySQL sucks bad enough that customers buy Oracle databases instead.
  • There is every reason to use MySQL: It is integrated in pre-configured LAMP stacks, it is ubiquitous, and it "just works". If MySQL isn't good enough, why would anyone change to MariaDB, which is - and will remain - 99% the same thing?

    This appears to be a guy trying to take back a product he already sold. Regrets? Doesn't know what to do with his life? Whatever...

Business will be either better or worse. -- Calvin Coolidge