As good as the relational database has been, developers need to embrace a diversity of databases to get their work done today.
Relational databases have been the norm for so long that we’ve forgotten that the relational database management system (RDBMS) is one way to model and access data, not the only way. Indeed, for modern applications, RDBMS may not apply at all.
Increasingly, however, as Amazon CTO Werner Vogels has explained in a new blog post, the answer to the question of “Which database?” doesn’t come with an “either/or” answer, but rather involves multiple databases to handle all the complexities of managing disparate, high-velocity data at scale. If you’re still trying to cram all your data into the tidy rows and columns of an RDBMS you’re not only doing it wrong, but you’re probably doing your business harm.
The one-and-only RDBMS
Vogels isn’t against relational databases. Far from it. In fact, as he points out, Amazon Aurora (an RDBMS) is the fastest growing service in the history of Amazon Web Services (AWS). Clearly there’s quite a need for relational data.
The problem, however, is that after decades of working with RDBMSes, many think it’s the only way to work with their data. As Vogels has written, this is 100% incorrect:
For decades because the only database choice was a relational database, no matter the shape or function of the data in the application, the data was modeled as relational. Instead of the use case driving the requirements for the database, it was the other way around. The database was driving the data model for the application use case. Is a relational database purpose-built for a denormalized schema and to enforce referential integrity in the database? Absolutely, but the key point here is that not all application data models or use cases match the relational model.
As much as database admins might have been content to perpetuate this approach forever, developers have been champing at the bit for a different approach—one that recognizes that different data needs different databases.
To read more click here.
