Use the database built for your access model

More specific discussion of "These sophisticated schemes work well for 1 GB of data but not so well for 1 TB of data" would be nice. Instinctively, multiple indexes be more useful on large datasets than on small. What works better on the bigger datasets?

I also felt uneasy in the piece about the transitions back and forth from "latency" to "throughput" without discussion of "concurrency". For example, "At present, a 7200-RPM disk has a seek time of about four milliseconds. That means it can find and read new locations on disk about 250 times a second. If a server application relies on finding something on disk at every request, it will be capped at 250 requests per second per disk" assumes a queue depth of 1, whereas "Assuming that writing a record of data takes five milliseconds, and you have to write 20 different records to disk, performing these operations in the page cache and then flushing to disk would cost only a single disk access, rather than 20" assumes that the writes can all be issued in parallel. Perhaps a discussion of Little's Law and how it applies to database architecture?

I agree that relational models have everything to do with deduplication.

It is one area where purity in mathematics translates well to solving practical problems. It is often the case that the theoretic models of computation or storage translate very poorly to everyday use. If they can be represented, they are done so at cost, and are therefore not applied.

Maybe I'm a pessimist, but I argue that, while normalization does do nice things for data consistency, people often use/used it because of disk storage savings. In my experience, they rarely, if ever, achieve a high enough level of normalization to get much benefit.

In addition to that, I think the author is also conflating "model" vs "implementation". Some of the legacy relational databases are somewhat slow, but 1 TB of data is hardly much even for something like PostgreSQL. The more sophisticated column-oriented databases and data warehouses would still be considered relational databases, and are much much faster (as I understand, for many applications, the primary downside of those is cost, rather than anything inherent in the relational model or the implementation).

New, redesigned OLTP systems like VoltDB are also much faster than the original disk-based RDBMSs for transactional workloads.

Not really (see below). The article confuses a number of things and assumes only the simplest or most naive implementations.

A graph database is essentially a relational implementation that supports recursive joins. While not part of the strictest, most minimalist relational implementation in theory, most mature SQL databases support this to some extent. Some databases that support recursive joins will limit you to directed acyclic graphs.

A document database is a relational database implemented around materialized joins. It saves you from doing common joins dynamically. This is more restricted than a graph because it is a directed acyclic graph only. Again, most mature SQL databases support this to some extent or another.

A relational database that supports both materialized and recursive joins has the same expressiveness as a document and/or graph database. However, it trades some query performance in those individual cases for flexibility and performance in other cases that both document and graph databases are relatively poor at. Document and graph databases have existed since databases were first invented. Most of the implementation optimizations for documents and graphs are optionally available in good SQL databasess.

Key-value databases are a different beast. Most people only consider primitive databases based on key equality relationships or ordered ranges, which are quite limited. You can also build them based on multidimensional spatial relationships (i.e. keys are hyper-rectangles that can be relatively addressed), which are equivalent in expressiveness to relational implementations. If you added recursive joins to implementations of the spatial variants, you'd again have something that could express all of the models mentioned.

In summary, these models are APIs, they are not fundamentally different things if the underlying database engine is adequate for the purpose. It is why, for example, PostgreSQL can be used quite effectively these days as a document database.

Ooh. Good question. In implementation, they end up looking a lot like key/value stores, since most of the ones I know are implemented as edge-vertex associations.

However, there is certainly a lot of specialized functionality on top of that. You can then turn around and apply both relational models and hierarchical models with them.

There are definitely some use cases for which I would heartily recommend a graph database over the others, so, yeah, it is another category. It is also something that should have been mentioned in this article. :)