Drizzle and Ruby on Rails

I recently went to the 2008 O’Reilly Open Source Conference to give a tutorial on plugins for Rails. I recorded it, and if you’re interested in understanding and building plugins, I think there’s some good stuff there.

What’s more exciting to me than that are the talks I attended. I saw Brian Aker, the director of architecture for MySQL and the maintainer of the C client library for memcached, talk about both memcached and his new project, Drizzle. In the FAQ for Drizzle, he says:

I’ve been wondering for a long time now about all of the changes post [MySQL] 4.1. I believe there is a large market of users who never wanted them, and never cared for them. I also wanted to question the foundations of what we built.

• So what are the differences between this and MySQL?

No modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, ACL. Fewer data types. Less engines, less code.

In his interview with Tim O’Reilly, Aker said that Drizzle’s intended for a different market segment, specifically for web applications. Whether it’s intended specifically for Rails or not, I think we have a lot to look forward to with Drizzle and Ruby on Rails.

Currently, ActiveRecord doesn’t use foreign keys without a plugin, views without a plugin, or many data types. The creator of Rails has called databases “a necessary evil for the object-oriented domain model,” which is maybe overstating the case, but definitely reflects the view that business logic, including relational mapping, should stay in the application layer. Drizzle shares this view.

One might ask how this is really different from SQLite. Unlike SQLite, Drizzle is focused on multi-core architectures, and assumes you will have lots of RAM to use for the database. This focus on multi-core will allow Drizzle to handle concurrent connections well (they are keeping transactions).

MySQL isn’t slow, but MySQL without features you aren’t using will be even faster. The Drizzle project’s in C and C++, but if you’re proficient with those, I highly suggest participating in its development. Their coding standards show a definite commitment to quality over feature quantity, which should make working on it a very rewarding experience.

Talking about Drizzle has created some interesting discussions in our development lab. We’re split on whether database-enforced relational integrity is necessary, or if pushing that to the application layer is a good idea. We’d love to hear your thoughts in the comments.