Since the dawn of the NoSQL revolution just three years ago, the entire point of rewriting a database from scratch has been to get around the traditional limitations of the relational database. Yet while these new database alternatives call themselves “NoSQLs,” it turns out that the one thing almost all NoSQLs and relational databases have in common is, in fact, SQL.

SQL is still the most popular method of accessing data, no matter the platform in which the data is stored. The TIOBE Programming Community Index for April 2012 showed that Microsoft’s and Oracle’s SQL extensions (Transact-SQL and PL/SQL, respectively) alone place the query language at No. 11 worldwide, right behind Ruby.

And even when NoSQLs don’t use SQL directly, they emulate it closely. Apache Hadoop’s Hive is a SQL-like query language. And when it comes to stacks, NoSQL now stands for “Not Only SQL.”

Eric Farrar, product manager at Sybase, said, “As databases are entering the cloud world, there is a lot of interest in NoSQL options. This has been getting at what has been perceived as limitations of SQL databases. If you take a look at the majority of NoSQL solutions out there, they tend to be focused around a few key areas in which, historically, databases have not been good at doing. One of those would be heavily unstructured data. The other is handling vast amounts of data, and dealing with the big-data problem.

“How does SQL fit into this world? I find they certainly have a fit for more structured data, and also around data that requires much more referential integrity. Specifically, we’re addressing an area where relational still is the right solution, but adding cloud benefits.”

Brian Aker, a fellow at HP and former director of architecture at MySQL AB, said that NoSQL databases aren’t mature enough to stand alone on the front lines. “Everybody’s talking about NoSQL, and everybody’s starting a new database company, and everyone thinks they’ll be the next billion-dollar company,” he said. “But the next billion-dollar company is Instagram, not the database companies. It’s a 10-year development cycle to build a product.

“For MySQL, coding started in 1995 or 1996. It took 10 years to get to 5.0. Now MySQL has a business future of 20, 30 or 40 years ahead of it. No matter what happens with big data and NoSQL, MySQL has a fantastic life ahead of it. You can build new optimizers and storage engines and APIs.”

That being said, NoSQL is still making inroads into enterprises. Dwight Merriman, CEO of 10gen (the company behind MongoDB), said that NoSQL has become just another tool in the enterprise toolbox.

“One thing we’re seeing,” he said, “is a lot of companies are picking one tool as a standard tool that is available for all departments: one NoSQL tool. They’re saying, ‘I’m giving you a relational database, some business intelligence database tool, and now a NoSQL, and those are the three you have to work with on the database tier.’ ”
#!
Thus, it’s now common to find NoSQL databases and traditional relational databases working in tandem. Baron Schwartz, chief performance architect at MySQL consulting company Percona, said that MySQL is mature enough to solve most problems in modern Web environments. The trick is to tune MySQL and to use a powerful transaction engine, both of which are common problems solved by many different companies, from Oracle to Percona. And once those problems are solved, the issue then becomes the handling of databases in a cloud.

Which is exactly the problem NoSQLs try to solve: how to store large amounts of data redundantly, consistently and in a highly available way. Throw partitions into that mix, and things become even more complicated, no matter the database.

Sybase has offered up its own solution to the partitioning problem with its SQL Anywhere offering, which quickly provisions database instances and keeps them separate from one another for multi-tenancy situations. “What we’re doing with SQL Anywhere On Demand is taking a fundamentally different approach to a cloud database,” said Farrar.

Marten Mickos, CEO of cloud computing software company Eucalyptus Systems and former CEO of MySQL AB, sees a bright future for SQL in the cloud, and more specifically for MySQL.

“People always said, ‘MySQL is just a glorified file system,’ and the Postgres guys said, ‘You may have the brand, but we have the product,’ and we just laughed at this. That’s how we became an agile, quick-moving animal: the dolphin,” he said at the MySQL Conference in Santa Clara in April.

“That’s what made MySQL suitable to use in the cloud. That’s why these old giants aren’t used in Web applications anymore. MySQL is the only surviving member of the relational era that makes it into this new world.”

Mickos admitted he was exaggerating a touch. Postgres is also quite popular in cloud environments, with Heroku and VMware both offering up their own cloudified versions of that open-source relational database. But no matter the cloud or application, it’s certain that relational databases are still here to stay.
#!
Quick chat with Drizzle founder Brian Aker
Brian Aker’s work at HP is on cloud-based MySQL deployment systems that will be made available in the company’s forthcoming public cloud offering. He is also the founder of the Drizzle project, which started out as an effort to rebuild MySQL 6.0 almost from scratch. Drizzle ended up becoming a MySQL fork, however. We caught up with him at the MySQL Conference in Santa Clara in April.

SD Times: What’s going on with Drizzle?
Brian Aker: Drizzle is an interesting learning experience. We released version 7.1 last year. [Drizzle] 7.1 has been largely done by, not myself, but many people who were never employed at Sun or MySQL or Rackspace. The community keeps thriving, and this is something that’s lost on people. True open-source projects should have a larger contributor list than one company. Drizzle 7.1 got released on the backs of a whole bunch of folks. The community is pretty well thriving.

After 7.0, there had been a giant thud, and nothing had been done. I said I’m going to see if this has a life of its own. If it does not, let’s put a bullet in its head. The aspect of Drizzle that interested me is, could we build another relational database done in a community way?

So Drizzle is moving along without corporate-sponsored development?
We do, actually, quite fine without it. If anything, we don’t have the ongoing corporate feature-of-the-week that someone, somewhere said we needed. There was something added in 5.0 with Cursors done based on a BEA Systems requirement. They’re gone now.

There were goals I had hoped we’d take on. From a standpoint of ‘the codebase compiles and builds way cleaner than any other codebase,’ could we actually take a codebase and crank up the warning system and see what compilers find? That part I’m pretty happy with. We still haven’t gotten around the InnoDB question. We were faster than MySQL, and then Oracle upgraded InnoDB, and we have not upgraded our version of InnoDB. They are faster. That’s a train we haven’t gotten off of.

I always believed it would take [Drizzle] a while to reach market acceptability. I never thought it would be one year or two years. It’s a long game. We see more work being requested on the JSON side for configuration work, and replication continues to be sought after. Those are the pieces that are interesting.