Maturing the NoSQL argument

A system cannot mature its way out of a fundamentally wrong architectural choice. Companies as modern and data-focused as Facebook, Google, and Cloudera continue to make meaningful investments in SQL technologies.
Written by Ryan Betts, Contributor

Ryan Betts is CTO at VoltDB.

Recently Max Schireson, CEO of MongoDB, shared his thoughts on relational databases. His statements deserve a direct and frank opposing response. Let’s walk through the myths that Mr. Schireson promoted.

Myth One: SQL is old (and old is bad).

"The database market is in need of a big change. The technology that people typically use, the database layer, was designed in 1970 with a very different set of requirements in mind."

In reality, modern SQL systems have been designed and deployed over the last 10 years to address both large volume analytic workloads and high-performance transaction processing workloads. Modern columnar OLAP stores offer combinations of rich query semantics and impressive data ingest rates that document stores certainly can’t match.

Meanwhile, transaction-focused modern row stores can perform millions of SQL database transactions per second enabling sophisticated real-time analytics and decisions.

Myth Two: Relational systems are limited by their data model.

"The first rule of a relational database is that every row in a table has to have the same set of columns as every other row, which we didn't think reflected reality."

All popular SQL systems support document types. Many of these at performance and benchmark levels that can’t be matched by document stores. In fact, a major advantage of SQL is the abstraction-from-storage model. Unlike document stores that require navigation-based proprietary querying, relational stores provide a clean abstraction that allows optimization of queries and variations in storage as appropriate to the problem.

The relative ease with which vendors integrated document-oriented types into the relational model shows the strength of this abstraction.

Myth three: Relational systems are limited by their storage model.

"When you enter an order into a relational database, it doesn't go into something that just holds the order as is. The order header gets stored somewhere, each order line gets stored somewhere else, the address information gets stored somewhere else."

Modern relational systems employ storage algorithms appropriate to the application – even the "big vendors" that Mr. Schireson uses as his straw man. Relational systems combine in-memory, columnar, row-store, flash and different indexing techniques into scalable, high performance solutions. Why can they do this while document stores are often stuck with naïvely buffer-cached mmap’d update-in-place storage layers? Because relational systems appropriately abstract users from storage via SQL and cost-based query optimizers.

Myth Four: Relational is not agile.

"Now you want to build applications in a much more agile way and include much broader and more varied sets of data. You need to be able to maintain those applications without down time and deploy them into cloud-style infrastructures and service massive numbers of users."

High availability, fault tolerance, cloud-friendliness, and scaling concurrent users have nothing to do with the relational model. Conflating these concerns is misleading. HA and fault tolerance concern transactionality and replication. Cloud deployment is about distributed architecture, careful I/O scheduling and the performance budget for virtualization. Agility is about time to deployment and time to value. ACID programming models and familiar SQL tooling enables both.

Myth Five: All NoSQL needs is "more maturing."

"But [relational SQL systems are] more mature and they've got this tool and that tool and they've got the skillset — it's that maturity gap that we need to close."

Relational systems are more mature. Not just by age, but they are more mature architectures based on decades of research, market acceptance and user feedback. The results are robust, modern, distributed architectures that leverage decades of experience to advance the state of the art. The toolset around relational SQL systems is mature because of standardization – in direct contrast to proprietary document interfaces.

A system cannot mature its way out of a fundamentally wrong architectural choice. The market chooses relational SQL systems over document-oriented proprietary systems not for lack of choice but for rational reasons. Relational SQL stores replaced document navigation models decades ago.

Companies as modern and data-focused as Facebook, Google and Cloudera have made and continue to make meaningful investments in SQL technologies. These investments are driven by user demands for improved interactivity with data, integration with standard tooling interfaces, applicability of existing user training and knowledge, and the need for meaningful query optimization.

Editorial standards