While NoSQL databases offer greater scalability and flexibility, they have their own limitations, Stonebraker said. By not using SQL, NoSQL database systems lose the ability to do highly structured queries with mathematical certitude. Built from relational algebra and relational calculus, SQL offers a mathematical assurance that a well structured query would capture all the data that it set out to capture, even if the query itself is highly complex.
Other problems: NoSQL can not provide ACID (atomicity, consistency, isolation, durability)-level operations, a widely used set of metrics that assure that a database-driven online transaction is carried out accurately, even if the system is interrupted. Assuring ACID compliance can be written in at the application layer, though writing the code for such operations "is a fate worse than death," he said. Lastly, each NoSQL database comes with its own query language, making it difficult to standardize application interfaces.
In contrast, NewSQL can provide the quality of assurance associated with SQL systems, while offering the scalability of NoSQL systems, Stonebraker argued.
The NewSQL approach involves a number of novel architecture designs, he noted. It eliminates the resource-hogging buffer pool by running the database entirely in main memory. It removes the need for latching by running only as a single thread of the server (though some overhead would still be needed for other locking operations). And expensive recovery operations can be eliminated in favor of using additional servers for replication and failover.
Stonebraker boasted that VoltDB's own system, which uses these NewSQL-styled approaches, can execute transactions 45 times faster than a typical relational database system. VoltDB can scale across 39 servers, and handle up to 1.6 million transactions per second across 300 CPU cores, he said. It also requires far fewer servers than a typical Hadoop implementation, doing the same work in 20 nodes that would require Hadoop 1,000 nodes to execute.
While the audience was comprised of NoSQL users and developers, many seemed to think Stonebraker's SQL-friendlier approach had some merit, even if they disagreed on individual points.
Dwight Merriman, a founder of online advertising company DoubleClick and one of the creators of MongoDB, agreed with Stonebraker that SQL itself doesn't prevent scalability and slow performance. But he argued that SQL may not be the language everyone would want to use to parse and query their data in the years to come. "I would like to use something a little closer to the original language" that his applications are written in, he noted. SQL-based stored procedures are particularly difficult to work with for many programmers, he said.
Stonebraker is confronting the correct problem, McCreary said after the talk. Processors are not going to get any faster, but chip cores will continue to proliferate. So the issue of scaling out across multiple processors needs to be addressed, he said.
McCreary also agreed with Stonebraker's view that NoSQL users don't have a unified query language, which will slow the adoption of NoSQL as a whole. But McCreary suggested languages other than SQL could be used as a unified query tool for new databases, such as XQuery, a query language for XML documents.
Oracle did not immediately respond to a request for comment.