Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Arch Linux: MariaDB replaces MySQL in repositories (archlinux.org)
212 points by mcrittenden on March 25, 2013 | hide | past | favorite | 64 comments


What a coincidence! Just today, Slackware also switched to MariaDB! [1]. Two weeks ago, it was openSUSE [2]. It's on the cards for the next Fedora release in May [3]. Wonder when will Debian (and its children) make the switch.

[1]: http://www.h-online.com/open/news/item/Slackware-Linux-switc...

[2]: http://blog.mariadb.org/opensuse-12-3-released-with-mariadb-...

[3]: http://www.h-online.com/open/news/item/Fedora-19-MariaDB-ins...


From the OpenBSD ports email list:

  Subject: NEW: MariaDB
  To: ports@openbsd.org
  Date: Fri, 22 Mar 2013 21:55:07 -0400

  Here is a new port of MariaDB.

  MariaDB is a fork of MySQL maintained in the open. The development
  environment is so much better than what has become of MySQL AB since
  Oracle took over Sun. They deal with security issues in a much better
  manner and don't try to hide the tickets or any details regarding the
  issues. Bugs are fixed much quicker and tickets in general are dealt
  with in a much better manner. MariaDB 5.5 will replace the current
  MySQL 5.1 port for the next release.

  ...


I know it's not exactly a huge distro, but Chakra did the switch almost two months ago.

http://chakra-project.org/news/index.php?/archives/3-Switchi...


Debian stable: Probably not for a while.

Ubuntu and Debian testing and up maybe sooner.


I would think that Debian would be especially sensitive to the Closed Source environment that Oracle is generating for MySQL. It seems like it would be an easy choice between two software stacks; one OSS and the other CSS. Granted, Stable probably won't move for at least a release cycle, but I would be disappointed if Sid didn't make the switch soon.

Ubuntu, on the other hand, doesn't have the same strong OSS sensibilities and will probably tow the Oracle line, at least for a little while longer.


> Ubuntu, on the other hand, doesn't have the same strong OSS sensibilities and will probably tow the Oracle line, at least for a little while longer.

Sorry to ruin your "Ubuntu is more closed" claim (seriously why even make that up?) but Ubuntu has been discussing switching to MariaDB at for the past year -- here are the last 2 blueprints with the progress:

- https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-... - https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-...

Also it's "toe the line", and we're toeing with Debian, it just happens to be the same person doing the work in Ubuntu and Debian, so doing the work in Debian and syncing to Ubuntu makes the most sense.


It's a pretty tricky business buying an open source company. You have to work with the community and existing people to maintain "master" of it. Oracle of course is not that company and so their subacquisition of mysql via Sun is now being pissed away in its entirety. If I were an investor I might have some questions.

*Edit: Sun dropped $1 billion on mysql. That's a lot of money to later just "lose"


I think it was a very deliberate strategy by Oracle to undermine open source RDBMs by extinguishing the number one solution if it failed to attract customers to Oracle db. Their major mistake seems to be that they underestimated just how skeptical the foss community is of them - and rightly so - and how fast it can re-group and create alternatives. But you know what I really like? The fact that virtually no startups these days talk Oracle when discussing big data, which used to be the domain that Oracle truly dominated. Seriously, when did you read about Oracle (db) here on HN? It's interesting that Oracle focused so much on fighting open source RDBMs when NoSQL databases were the real threat all along.


Is the fact that almost no startups talk about or use Oracle that much of a problem for Oracle? Those startups wouldn't have generated much revenue for Oracle anyway. Those startups will forever be in search for a free solution.


An entire eco system - many which are at the forefront of big data - disinterested about Oracle's products is cause for concern, yes. And it's not just the startups but every person who reads about and tries to emulate them in the future, people who are now very unlikely to even look at Oracle's offerings let alone use them.


I don't think those people and corporations matter to Oracle.

Oracle doesn't go after startups. Or even companies like Facebook or Dropbox etc.

It goes after: government agencies, banks, insurance companies, multi-nationals, huge retail chains, logistics, payroll, and such. And it does a killing at it.

Web style big-data are not Oracle's domain.

And it's not like those startup people will afterwards (when they "grow up") go work in the enterprise and use Mongo and MariaDB there. It's just different kind of problem domains altogether.


What about when startups grow? Take Facebook as an example. Microsoft seems to be doing a good job targeting startups with Bizspark - not sure if Oracle has a similar program.


Microsoft seems to be making an effort with BizSpark, I don't know that I'd call it "a good job" in terms of actually getting startups to adopt MS stacks for the basis of their tech.


Only a few, but some of those startups will become the software giants of tomorrow and they will not use anything from the Oracle ecosystem. Something to be really worried about.


>Only a few, but some of those startups will become the software giants of tomorrow and they will not use anything from the Oracle ecosystem. Something to be really worried about.

As per my comment above, Oracle doesn't care about those startups, whether they become the "software giants of tomorrow" or not.

They sell to government agencies, logistics, payroll, multi-nationals, banks, finance, insurance companies, etc.

Those sectors do not overlap with the startups using MariaDB, Mongo, or what have you. Totally different problem domains and people.


Startups targeting enterprise or government customers might well use Oracle. It's free* to develop on, and something a lot of those sorts of clients use anyway.

* Last I checked, Oracle allowed you to use Oracle RDBMS free for "prototype development" but once you were actually generating revenue from that you are supposed to buy the necessary licenses, even for continued development or support purposes.


It's still the case - we had a free license from Oracle for the first 3-4 years of our company's life - We just had an account manager call us ever 6-9 months, see how we were doing. Eventually we got some real customers, revenues, and negotiated a several million dollar license purchase + 18%/year maintenance.


> Oracle allowed you to use Oracle RDBMS free for "prototype development" but once you were actually generating revenue from that you are supposed to buy the necessary licenses, even for continued development or support purposes.

Hm... I vaguely remember (but it was a really, really long time ago) you could use Oracle for as long as you wanted as long as you didn't process your own or your customers' business data.


It could be, fast forward ten years and the majority of the smartest minds in the industry will have no experience with your flagship product.


Oracle (and IBM) will continue to dominate in industries that are not particularly subject to competition (especially not from startups), due to regulatory capture.

In particular, this is banking (an extremely heavily controlled industry), and telecom (regulation here is mainly just to keep out competition, not as much to control).


This is a really narrow-minded perspective, and quite incorrect. Oracle and IBM will continue to do well in big organisations where the company isn't IT-focused, and where the license cost makes sense. I see a lot of big Oracle HA configurations where downtime or data-loss is unacceptable (and very pricey), where management wouldn't risk their careers choosing something that a start-up would consider.

You're going to see more open-source based solutions on the periphery, but core systems are a whole different thing.


> This is a really narrow-minded perspective, and quite incorrect.

I agree that it's sort of narrow-minded, in that there are reasons to use Oracle and IBM outside of the industries and use cases I singled out. I'm not sure why it's incorrect, though (feel free to enlighten me).

where the license cost makes sense. I see a lot of big Oracle HA configurations where downtime or data-loss is unacceptable (and very pricey), where management wouldn't risk their careers choosing something that a start-up would consider.

Is it really true that Oracle's products are superior if you're going for "no downtime, no data loss, cost not so important"? I don't have any experience in that arena. But I would expect an open source options to be competitive.

If the Oracle products are really worth it, what explains that?

Is it that you can get Oracle people on the phone at any hour whose sole job is to fix it, and there isn't similar open source support? (If so, why isn't there? Red Hat plays this role for Linux.)

Is it that Oracle software is just too complicated and well-done and smart to be replicated in the open source world? "In theory," that should not be the case, but maybe the database equivalents of Linus Torvalds always end up just working for Oracle, or something.


> Is it really true that Oracle's products are superior if you're going for "no downtime, no data loss, cost not so important"? I don't have any experience in that arena. But I would expect an open source options to be competitive.

Pretty much - Oracle's clustering/replication options are still considerably superior to even a 'real' open source RDBMS like Postgres (as well as providing better performance). MySQL, by contrast, is missing so many important capabilities (transactional DDL, check constraints, window functions, joins other than nested loop) that it's not (imo) especially worth considering.

If you look outside the realm of open-source RDBMSs to NoSQL, you tend to find that they'll be missing some critical feature for reliable database operations, like transactionality, or simply won't be that feature rich (i.e. key-value stores). This is not to say that NoSQL stores don't have a place, just that they tend to be designed around web use cases where trading off consistency can be worth it.

I'm not meaning to hate on open source DBs here - I think Postgres is fantastic and easily sufficient for most use cases. Technologically Oracle/DB2 are still better products, though.


There are a number of reasons why Oracle dominates the enterprise and will forever remain so.

One. The products are well understood. Not just from a technical perspective but operationally as well. Generally enterprise companies have dedicated DBAs either in house or on call. Two. There are unlimited support options. Three. Almost all enterprise software works with Oracle and many are only supported for use on Oracle.

You ARE seeing open source adoption in particular MongoDB, Cassandra in specific areas of the business. But they are almost exclusively "non-core business".


I spent some time last year at a bank setting up an Oracle DB that would replicate data from MongoDB, for reporting. The Oracle DB, once set up right, was considerably faster with the queries we wanted than MongoDB, and that was in between running massive imports. MongoDB was running on 6 big physical boxes with loads of RAM, while Oracle DB was only running on a single virtual machine using 16GB of RAM. The reason this worked was because of the wealth of Oracle knowledge out there, access to experienced DBAs with knowledge of good methods, etc. I found MongoDB to be a bit young in this sense, performance tips were down to 'change your schema' which is also true for Oracle but there are many ways to make Oracle work better with a legacy bad schema. That said Cassandra, MongoDB etc. seems to be taken up by the banks at a rapid pace, mainly for analysis tools e.g. in trading.


"Forever remain so"? It's impossible that the infrastructure you describe could eventually exist for another database?


The problem with that perspective is that as markets shift over time, what was once the perifery will soon be the core. That will put the open-source solutions that can handle it in a very good spot long term, as these are exactly the kind of systems that don't end up with big rewrites of their data layer.


A good number of my consulting clients start off by telling me they think that they'll need Oracle.

When it comes to the people in charge of the money, it seems Oracle's not doing too bad a job.


Wasn't it PostgreSQL the RDBMS that was competing with Oracle anyway? And PostgreSQL has been doing fine lately.


Looking at the specs for MariaDB, I can see why our last client dropped MySQL for the front end and went with it.

The XtraDB engine, basically a fork of InnoDB with patches, is actually very nice. We've had to do almost no modifications to the data structure when moving from InnoDB for some DBs (that we're not using Postgres for).

Fun fact: XtraDB is also the default in Percona http://www.percona.com (No, I don't work for them).

There are things you still need to carefully look into before migration if that's what you want to do. Minor things like naming is only part of it. Read. Read. Re-read the documentation : https://mariadb.org/docs

I've felt MairaDB is the direction MySQL should have gone after the 4.x branch. In many ways (though the technical aspects are totally different), this split is very similar to what happened with FreeBSD after the 4.x branch with the start of DragonFly. When in doubt, fork.

The beauty of Open Source.


XtraDB is not only the default in Percona, they originally wrote it (forked from InnoDB).

http://www.mysqlperformanceblog.com/2008/12/16/announcing-pe...


Out of curiosity, why do you need to use both Postgres and MySQL/MariaDB?


Our clients usually have a lot already running on InnoDB so we always have similar setups (preferably identical except the same volume of data) to what they have on the side. Can't tell you how many problems we've caught that way and how much it simplifies things during deployment. If starting anew, it's Postgres.

Our internal stuff is almost all running straight Postgres but a small part of our application stack is abstracted on top of it to provide document DB functionality.


Mysql cannot do parallel query. That's a single query won't spin off multiple threads and work in parallel. This makes it a bad solution for say aggregating over large data. Mysql can handle lots of threads(queries) in parallel making it an ideal solution for web.

Postgres can do parallel query.


MySQL can do parallel querying through some of the less common back-ends, like Infinidb, which are more suited to warehousing than OLTP like InnoDB/XtraDB.

http://infinidb.org/component/content/article/53/158


PostgreSQL doesn't do parallel query.


That said, if you can, use PostgreSQL for the good of your head. Transactional schema migrations mean you can save yourself a lot of headache.


Is there a good reason to use MySQL when you have the choice between it and Postgres? When we had the MySQL vs Postgres discussion in college, it seemed like the only reason to use MySQL we could come up with was that it had the larger user base.


Traditionally MySQL has been ahead of Postgres in terms of replication, but Postgres has made great strides in that department recently. Having said that, Postgres still doesn't support master-master or ring topologies, replication filtering, and is binary only (which is probably a good thing).


Naah, I wouldn't go so far to say it's a good thing that it's missing, but it's hellaciously hard to implement well. I think the sentiment is rendered well in this mail, which took place after extensive review and hacking. In it, Robert Haas (a committer) writes to Andres Freund (the principal author, I believe):

  Before getting bogged down in technical commentary, let me say this
  very clearly: I am enormously grateful for your work on this
  project.  Logical replication based on WAL decoding is a feature of
  enormous value that PostgreSQL has needed for a long time, and your
  work has made that look like an achievable goal.  Furthermore, it
  seems to me that you have pursued the community process with all the
  vigor and sincerity for which anyone could ask.  Serious design
  concerns were raised early in the process and you made radical
  changes to the design which I believe have improved it tremendously,
  and you've continued to display an outstanding attitude at every
  phase of this process about which I can't say enough good things.
  There is no question in my mind that this work is going to be the
  beginning of a process that revolutionizes the way people think
  about replication and PostgreSQL, and you deserve our sincere thanks
  for that.
 
  Now, the bad news is, I don't think it's very reasonable to try to
  commit this to 9.3.  I think it is just too much stuff too late in
  the cycle.  I've reviewed some of the patches from time to time but
  there is a lot more stuff and it's big and complicated and it's not
  really clear that we have the interface quite right yet, even though
  I think it's also clear that we are a lot of closer than we were.  I
  don't want to be fixing that during beta, much less after release.
http://www.postgresql.org/message-id/CA+TgmoYhkMpkB8JZYhVei-...

The implications for PostgreSQL version upgrade alone are enormous. MySQL has been ahead here, even though some if it was at the cost of some sanity, and by lack of sanity I mean "statement based replication". The first semi-sane logical replication was the 2008 release that included row-based-replication.


We use both in our production and staging environment. I've been using both for the last 3 years (5 years for MySql). My opinion at this time is that in 80% of cases MySQL is easier to setup, use and manage.


Only if 80% of the use cases are extremely simple use cases, with no need for multiple indexes per table, complex queries, common table expressions, user defined datatypes, window functions, asynchronous queries, or a strict stance on undefined behaviors, etc.

The problem I see is that simple use cases gradually become slightly-less-simple use cases. And the pain of switching is 1000x the pain of taking a few extra steps up front and using a better database.


I doubt all the stuff you listed is used even in 1% of cases, except multiple indexes and strict stance. And MySQL supports both.


All the stuff, sure. But I have yet to find a scenario that doesn't involve at least one of them.


I've been using both for 10 years; postgres for in house apps, my SQL when a third party app needs it, and I find postgres much easier to manage.


The only one I can come up with is that Sequel Pro supports MySQL and not PostgreSQL.

Truly, the one item I miss the most from making the switch.


I prefer Postgres wherever i can, i usually go with MySQL(or RDS) whenever i'm on AWS. Since the added features of multi-AZ, and scalability take a lot of upfront effort/time investment away.


My favorite comment from the comparison page

https://kb.askmonty.org/en/mariadb-vs-mysql-compatibility/

"Timings may be different as MariaDB is in many cases faster than MySQL. "



I'm hardly a DB expert, but I would have thought Percona would make more sense to replace Oracle MySQL in the repository. True it doesn't have a few new bells, but it should be a drop-in replacement for pretty much everyone.


For any arch'ers looking to upgrade, note that "mysql_upgrade -p" can take a long time depending on how much data you have in MySQL. It took a few minutes on my laptop with only a few medium sized databases.


Interesting performance comparison here between MariaDB, Percona Server, and MySQL http://vbtechsupport.com/657/2/


I went to Open Database camp a few weeks ago. There was a talk about the split...

The short story: MariaDB is a fork of MySQL done by Michael "Monty" Widenius one of the mySQL founders.

It seems the winds of fear are blowing against mySQL and MariaDB is getting mindshare (it is a fork so pretty close still but not going back). Although Oracle hasn't really done anything yet, and did send a rep to the conference, there seems to be some distrust.

About a decade ago at a startup we had and Oracle instance running s a test, their sales people where tenacious (fought them off by asking for an ODBC driver for linux). Then startup went under. sigh.


My prediction is that in the next few years Oracle will give up on MySQL by either abandoning it or give it to the foss community. Because once the enthusiasts, devs and hackers lose faith in your foss project - it's done for. Just look at what happened to Open Office.


But first they'll try to sue a bunch of people.


I don't see them giving up the copyrights. As it is GPL, nobody else is going to go opencore with it or having a separate commercial license. Which puts a spanner in the works for MariaDB and other MySQL-based competitors (Monty did in fact complain about it a while back).


Hopefully Ubuntu makes a similar switch in the near future. Long overdue at this point.


Totally agree. I have been feeling this gut for nearly everything open-source out there. It's time to reign-back-in! Sorely.


The interesting part about this is that MariaDB is only a drop in replacement for MySQL 5.5. MariaDB isn't porting to MySQL 5.6 (which came out last month), instead they are going to try to reimplement all of the functionality from MySQL 5.6 which will probably never finish:

http://blog.mariadb.org/mariadb-10-0-and-mysql-5-6/


Slackware is doing this too.


Apparently Fedora and SuSe also decided to a while ago.

https://news.ycombinator.com/item?id=5147574


How easy is it to switch a production environment (millions of users, TBs of data) from MySQL to MariaDB?


Is MariaDB Galeria Cluster mostly-the-same as MySQL Cluster?


The queen is dead. Long live the queen.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: