MariaDB 10.0 Beta launched | Hacker News Reader

MariaDB 10.0 Beta launched

blog.mariadb.org

I've been impressed with Postgres, and still have a sour taste in my mouth over MySql's sale to Oracle. So why would I want to use MariaDB over Postgres? Is there a compelling reason to give it a look?

The main stronghold of MariaDB is the drop in replacement for MySQL. If you already have a well established web app and you are planning on get off the clutches of Oracle, MariaDB is your easy choice. You don't have to make substantial changes or worry about breaking any existing functionality. As for performance, can someone who have used both comment on it? Also anyone knows if any exciting changes coming to MYSQL? Can't believe MySQL still doesn't have support for Json.

I am pleased to see that the traditional SQL databases are still advancing. Having used various NoSQL databases, I always miss the declarative nature of SQL.

I have to agree that MariaDB's main stronghold being MySQL drop in. The other MySQL drop in out there is MemSQL, which is closed and they really keep pricing under wraps.

TokuDB is a great engine. I don't think Postgres has a storage engine that matches the benefits TokuDB brings, but other than that I don't see many benefits over Postgres for a new project, but haven't compared the replication features closely.

Migrating a big codebase to Postgres from MySQL can be kind of a pain unless everything wrapped everything in an ORM like sqlalchemy. The main pain point for me in a recent migration was how postgres handles mixed case in table/column names. Most of the function differences between the two are fairly easy to resolve.

Can anyone with experience with JSON in both Postgres and MariaDB make a comparison?

> TokuDB is a great engine. I don't think Postgres has a storage engine that matches the benefits TokuDB brings

I have heard about TokuDB but I can't find any good resources to explain why it's so good and what it does differently. Do you know of any? The page on the MariaDB site (linked to from the OP) says very little...

Thanks!

> I am pleased to see that the traditional SQL databases are still advancing. Having used various NoSQL databases, I always miss the declarative nature of SQL.

And I bet you haven't seen Datalog yet. ;-)

Oh I have, and I like it so much that I feel like mentioning all the time. So I was pleased with my self-restraint here ;)

The replication you get when you combine it with Galera. If postgresql had that I would drop mariadb, but the painless replication and having multiple read write masters is too good to pass up on. Conversely if Mariadb would add the json data types that postgresql has I would probably never think about moving.

For those, like me, that hadn't heard of Galera before, it's a library that ships with(?) mariadb, and is also being developed for postgresql (no release date). Fully open source, and at least on paper, looks great (I have no experience with it):

http://codership.com/products/galera_replication

http://codership.com/products/postgresql_galera

Might be off topic, but for anyone interested in porting your data over from MySQL to Postgres, I found this[0] useful from the Postgres docs.

I had to edit it very little to fit how my data was stored, and imported it successfully to work within Django.

[0] https://github.com/lanyrd/mysql-postgresql-converter

Not off topic at all, thanks. The only time I've ever heard of people using MariaDB was because they were using MySql. Sure, its a valid reason to pick a technology, but its got to be be one of the worst reasons.

There's also Percona's fork of MySQL.

MariaDB incorporates Percona XtraDB.

according to this[1] it is not included in the beta version. Having said that, Percona is not only XtraDB

[1] https://mariadb.com/kb/en/about-xtradb/

    DELETE ... RETURNING

Cool! The ability to fetch the result of a write operation without having to do a SELECT afterward is one of my favorite "minor perks" of PostgreSQL. It eliminates the need for a lot of extra queries.

With MariaDB 10.0, only DELETE statements get the RETURNING clause. But it seems that they have plans to add it to UPDATE statements soon [1], and I hope INSERT gets it as well.

[1] https://mariadb.atlassian.net/browse/MDEV-5092

Has anyone done a conversion from mysql to mariadb recently? How was the experience?

Seamless. I'm not using stored procedures, views, etc., but for some simple InnoDB databases, MariaDB was a drop-in replacement. The command line tools are even still called mysql.

I maintain a reasonably complex web app in production that uses stored procedures extensively. I am running it in production with both MariaDB 5.5.x and MySQL 5.5.x.

I have not experienced any compatibility issues with MariaDB vs. MySQL.

We're currently doing one. It's been relatively painless, most of the difficulty being simultaneously moving off old myisam tables to innodb -> xtradb

I develop a Rails 3 web app and recently moved from MySQL to MariaDB. Well actually the guys at Rails Machine did the move for me. I don't know what all they did on their end, so can't speak much for the server admin side. We ended up making the switch since I was moving to a high availability setup with multiple DB servers.

On the web app side, I am using the mysql2 gem and made zero changes to my code. Also, I frequently import SQL dumps from MariaDB into my local MySQL development with no problems.

The only issue I had was related to some nasty SQL I had in a select in a finder (yeah I know bad practice). MySQL was returning a 0 while MariaDB returned NULL. Either way, it was my fault for messy code and when I fixed the select, everything was good.

There's one silly difference I noticed. Timestamps in mariadb dumps have their size appended. Mysql doesn't like that, so you need to filter them out. Otherwise pretty much a drop-in.

Recently upgraded from MySQL 5.1 -> MariaDB 5.5 with no issues what so ever. We have ~90 tables where the largest table has 40,000,000 entries.

I configured the new database servers as slaves of the old ones. This enabled me to verify things in production and do a safe upgrade. Promoting the MariaDB slaves to master was the only required action in terms of switching over. No code changes were required in our application code.

We were thinking about it. I fired up our apps testsuite and found a bug: https://mariadb.atlassian.net/browse/MDEV-4711

The bug was now been analyzed but not fixed for ~3 releases.

That said I also ran the testsuite against 5.6 and found some problems, too. You might also be concerned about http://bugs.mysql.com/bug.php?id=69274 - this means that if you loose an idb file during a crash you're out of luck to use your db ever again.

We're thus currently stuck at percona server 5.5 with regular investigation of the alternatives.

What is involved in changing from 5.5 to 10.x?

Reply on news.ycombinator.com