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.

SEE: Data classification policy (Tech Pro Research)

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. As Vogels continued:

Seldom can one database fit the needs of multiple distinct use cases. The days of the one-size-fits-all monolithic database are behind us, and developers are now building highly distributed applications using a multitude of purpose-built databases. Developers are doing what they do best: breaking complex applications into smaller pieces and then picking the best tool to solve each problem. The best tool for a job usually differs by use case.

And so AWS has built not one, but many different database services. The company is trying to anticipate and match “the categories of nonrelational databases [that] continue to grow,” Vogels noted.

More choice, more good

As good as those AWS options are (and their rocketing popularity on the DB-Engines ranking system suggests that they are), the point isn’t that developers should slavishly use only AWS database services, just as they once defaulted to Oracle, specifically, and RDBMSes, generally. No, the point is that, for the first time in a long time, developers have a real choice as to how to build their applications.

SEE: Special report: The cloud v. data center decision (free PDF) (TechRepublic)

The key is to get away from application monoliths and instead break down applications into independent, component parts, each fulfilling a specific job. Those jobs, in turn, demand different databases to drive them, increasing an application’s scale, flexibility, and utility.

It’s about time. As great as the relational database has been for the evolution of computing, it has now become a stumbling block to developer productivity. By breaking out of of the RDBMS echo chamber, companies like AWS, MongoDB, Microsoft, and more are enabling developers to express their creativity in hitherto impossible ways. It is, in short, a great time to be dealing with data.