Amazon had the first word on NoSQL. In Dynamo: Amazon’s Highly Available Key-value Store published in 2007, Amazon said:
“For many services, such as those that provide best seller lists, shopping carts, customer preferences, session management, sales rank, and product catalog, the common pattern of using a relational database would lead to inefficiencies and limit scale and availability.”
This echoed the argument from the days when object databases seemed to threaten the future of relational databases:
“Using tables to store objects is like driving your car home and then disassembling it to put it in the garage. It can be assembled again in the morning, but one eventually asks whether this is the most efficient way to park a car.”
The quote is incorrectly attributed to Esther Dyson, the editor of a newsletter called Release 1.0. But in the September 1989 issue of Release 1.0, she did say:
“You can keep a car in a file cabinet because you can file the engine components in files in one drawer, and the axles and things in another, and keep a list of how everything fits together. You can, but you wouldn’t want to.”
In May 2011, Oracle Corporation published a criticism of NoSQL called Debunking the NoSQL Hype, the last words being:
“Go for the tried and true path. Don’t be risking your data on NoSQL databases.”
And the hearts of the faithful were gladdened.
In September of that same year, Oracle Corporation released Oracle NoSQL Database and said:
“The Oracle NoSQL Database, with its ‘No Single Point of Failure’ architecture, is the right solution when data access is ‘simple’ in nature and application demands exceed the volume or latency capability of traditional data management solutions. For example, click-stream data from high volume web sites, high-throughput event processing and social networking communications all represent application domains that produce extraordinary volumes of simple keyed data. Monitoring online retail behavior, accessing customer profiles, pulling up appropriate customer ads and storing and forwarding real-time communication are examples of domains requiring the ultimate in low-latency access. Highly distributed applications such as real-time sensor aggregation and scalable authentication also represent domains well-suited to Oracle NoSQL Database.”
And the hearts of the faithful were saddened.
In 2014, Google, which recently created a new DBMS called F1 for its business-critical AdWords application. Point be made that Google implemented a version of Oracle Database table clusters in order to avoid the join penalty. In F1: A Distributed SQL Database That Scales, Google said:
“In recent years, conventional wisdom in the engineering community has been that if you need a highly scalable, high-throughput data store, the only viable option is to use a NoSQL key/value store, and to work around the lack of ACID transactional guarantees and the lack of conveniences like secondary indexes, SQL, and so on. When we sought a replacement for Google's MySQL data store for the AdWords product, that option was simply not feasible: the complexity of dealing with a non-ACID data store in every part of our business logic would be too great, and there was simply no way our business could function without SQL queries. Instead of going NoSQL, we built F1, a distributed relational database system that combines high availability, the throughput and scalability of NoSQL systems, and the functionality, usability and consistency of traditional relational databases, including ACID transactions and SQL queries. Google’s core AdWords business is now running completely on F1. F1 provides the SQL database functionality that our developers are used to and our business requires. Unlike our MySQL solution, F1 is trivial to scale up by simply adding machines.”
But Google has not released F1 for public consumption and so the last word on NoSQL goes to the creator of relational theory, Dr. E. F. Codd, who said in a 1986 article:
“Any buyer confronted with the decision of which DBMS to acquire should weigh three factors heavily.
The first factor is the buyer’s performance requirements, often expressed in terms of the number of transactions that must be executed per second. The average complexity of each transaction is also an important consideration. Only if the performance requirements are extremely severe should buyers rule out present relational DBMS products on this basis. Even then buyers should design performance tests of their own, rather than rely on vendor-designed tests or vendor-declared strategies. [emphasis added] …
The second factor is reduced costs for developing new databases and new application programs. Due to 1} the high level, simplicity, and conciseness of relational languages, and 2} the forgiving nature of relational systems if the database is initially poorly designed, relational DBMS provide significant reduction in these costs, when compared with [other] approaches. …
The third factor is protecting future investments in application programs by acquiring a DBMS with a solid theoretical foundation …
In every case, a relational DBMS wins on factors two and three. In many cases, it can win on factor one also—in spite of all the myths about performance.”