Drizzle, the MySQL killer

[Highland]

It's not often you can say that one open source project will replace another but it has happened. Drizzle GA has arrived.
http://drizzle.org/

I've been following this for over a year and I've mentioned it here a few times. Drizzle is not like other projects (like PostgreSQL) in that it is forked from MySQL and seeks to maintain compatibility with MySQL. Basically, the Drizzle project tore MySQL down to its base code and kept it there. Several key features are

• Plugin based. No more are things built into the core. Want a new feature? Build a plugin
• Native multi-core support (this is a feature of MySQL 5.5 as well)
• Better memory handling
• Vastly improved replication (with native and plugins to choose from)
• Too many other differences to list here

In short, Drizzle aims to be what MySQL has failed to be (and what Oracle doesn't seem to care too much for): a true open source database. No more filing bugs and feature requests. If Drizzle doesn't work for you, odds are you can find (or write) a plugin that makes it so.

Some more good news is that they are making their builds available via their own yum channel so we don't need the atomic-bleeding builds Scott had talked about before.

I predict that within 5 years MySQL will be mostly replaced with Drizzle. It won't happen overnight (even I can't migrate yet but I am testing) but it will happen as people get tired of MySQL and realize that Drizzle is where the community has moved.

[hostingguy]

I dont know if Drizzle does this, but for this I am going to assume they dont - but as long as mysql offers corporate support packages they will never go away. I also dont see anything huge that Drizzle can do that mysql cant do - until there is that "killer feature" I doubt you see many people migrate away from something that currently "works".

Also, I have to disagree with this statement:

Drizzle does not currently have any plugins that implement stored procedures [...] Fundamentally, stored procedures usually are not the correct architectural decision for applications that need to scale. Pushing more computation down into the database (which is the trickiest layer to scale) isn’t a good idea.

Stored procedures though are usually used by companies that want to keep code and db seperate - check in their sprocs into a source control, and keep the DB guys out of code. Those people probably already use oracle or ms sql, so it may not be a big deal. The way mysql currently does that is pretty crappy, and I think that if they had focused more on that part they could have gotten a bigger following more quickly for those people who are looking for an alternative to those or have outgrown mysql capabilities. Also no triggers or views - although they can have a "plugin" for that - but that seems like something that should be a native functinoality to me.

[scott]

Wait, stored procedures are basically putting programming into the database. I don't like that for 2 reasons:
1) Database programming languages are not sophisticated, and I object to putting programming into something big/dumb/heavy like a database. Programming logic belongs in places where you can abstract and scale it horizontally across lots low complexity systems. This is super important if you want to do anything serious (like google, wikipedia, or facebook. Note these guys dont use mssql or oracle). The stored procedure approach forces you to scale linearly into large monolithic database systems. Thats only a good idea if you want to increase the value of my oracle stock (um... which I do.)

2) It justifies employing someone as a "DBA". I don't even know what the hell DBA's do. They certainly don't do any real work aside from making what they do appear so complicated and important as to justify their existence.

So to sum up:
1) you shouldn't use oracle if you want to do anything serious
2) you should use oracle.

[hostingguy]

DBAs are supposedly "admins" - you dont need them unless the server breaks. In the event of needing something done you would talk to a db dev, and not a db admin

[Highland]

Keep in mind that Drizzle is still young. The beauty of Drizzle is that, while the core guys don't want to write something to do stored procedures, someone else could come along and write a plugin for it.

Parsers are where you spend a lot of your time. The smaller the parser the better off you are.
*snip*
Any language should be pluggable. We won't have a native language.
*snip*
I am a little bit torn about using the SP call/creation SQL commands in Drizzle. You won't be doing the typical SP language (well... unless someone wants to write a plugin for them!). I would also like to encourage people to think differently about what writing server side code should look like. Personally I don't feel that stored procedures are the right solution for a lot of the cases, keep your business logic in your application layer(!), but we also know that users expect to be able to be able to run code locally. Triggering/Callback mechanisms can be very useful though, and enabling them is a part of this. Doing Triggers today in C is simple, but that is not something that everyone should/would/could want to do.

http://krow.livejournal.com/638941.html

And there are better reasons than even Scott mentioned for not doing stored procedures (which you could do if you really want to get crazy with C in your SQL)
http://www.flamingspork.com/blog/2010/0 ... r-drizzle/

[hostingguy]

The concept is nice, but I seriously doubt this will have any significant market share, or take any users away from mysql, oracle, mssql, postgre or anything else. At best it will be "Drizzle, the thing MySQL considers to be a fly" (something that is annoying and buzzes a lot but doesnt do any damage to anything) rather than a killer

[Highland]

I don't see this as competing with Oracle or MSSQL (not in a direct sense anyways). Postgre is a horse of a different color entirely (not much supports its use). I suspect, however, that Oracle is going to put MySQL to pasture. In other words, whatever succeeds 5.5 will probably the last (see Open Office). It won't stop being GPL, they just won't fund building open source anymore. Remember, MySQL Enterprise isn't significantly different from the community version. I think Oracle will create a lower "entry tier" to Oracle's DB (I bet it even would support the MySQL language) and gradually shunt Enterprise users over there.

This won't happen overnight. But I really think that MySQL as MySQL is a dead project walking. Even if Oracle doesn't kill it, Drizzle is built to avoid major problems in MySQL and is getting tons of community support.

A better list of improvements can be found here
http://krow.livejournal.com/700783.html

[scott]

I definitely think it warrants being added to the repo, its on the list!