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.
Postgres (Score:5, Informative)
...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.
Re:Postgres (Score:4, Informative)
I'm confused, on my debian vps, another debian dedicated server and a further centos server, I could just apt-get the new software.
since it's 100% compatible and most small websites are not even going to touch the potential problem areas, how would this cost a "lot of money" ?
I could upgrade my database in the time it takes to download the packages, hardly a lot of money and even less of time.
There Is No Reason At All To Use MySQL.. (Score:5, Informative)
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:Postgres (Score:3, Informative)
I've heard that for years, but is Postgres better than MariaDB?
MariaDB is a fork of MySQL. So the answer is a resounding yes, in every way, no matter what your target platform is.
Re:There Is No Reason At All To Use MySQL.. (Score:2, Informative)
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.
Re:Postgres (Score:2, Informative)
True, but in regards to the existing customer base, I wouldn't be terribly surprised if MariaDB has better compatibility. If you are migrating to a new version, there might be less trouble with MariaDB.
OK, logically, riddle me this: how does a replacement possibly have "better compatibility" than the very thing for which it is a "drop-in replacement"? You see, it makes no sense. At most, it could only achieve equal compatibility, otherwise any substantial differences render it other than a drop-in replacement.
What was your point again?
Re:Uh, what? (Score:4, Informative)
and being purely selfish with ZFS is just nauseating anymore.
Uhm, your saying that its Oracles fault Sun and many other people dont' like the viral nature of GPL and intentionally licensed the software in such a way that prevents your silly fanboy license from being able to leech it? You're saying that its okay for you to have software your way ... but not for anyone else to be free to have it their own way.
You're just another one of the freeloaders. Any talk about liberty is just bullshit your spewing to hide the truth.
My OS has been using ZFS for years without any problems, stop your whining, you got what you intended out of your license. GPL is incompatible with ZFS, not the other way around. Get a clue
Re:or sqlite (Score:5, Informative)
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.
Ask and ye shall receive:
http://phppgadmin.sourceforge.net/ [sourceforge.net]
Re:Postgres has a poor toolset (Score:5, Informative)
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.
Re:Postgres has a poor toolset (Score:5, Informative)
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.
Re:Free migration then? (Score:4, Informative)
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.
Re:or sqlite (Score:5, Informative)
The default configs for postgres are set for a fairly small memory usage profile (*), which is fine if that's what you need (e.g. tiny vm or something that makes it a huge production to raise things like max shm size), but if you have sufficient ram, you can crank a hell of a lot more performance out of the engine by making the configs less conservative. This page is a good start: http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server [postgresql.org]
Not that it's a priori *wrong* to run with the defaults, it'll still work just fine, but once you start having significant traffic or complicated queries you'll be happier if it more fully uses the system resources available.
(*) It's been a good while since I last had to take a pg instance from stock and tune it, but I very vaguely recall the default settings were on the order of a eight megabytes of ram usage.