Home Relational Databases Aren’t Dead. Heck, They’re Not Even Sleeping

Relational Databases Aren’t Dead. Heck, They’re Not Even Sleeping

To listen to the media, you would think that the end of the relational database is about to strike at any moment, leaving behind a shattered mess of tables and queries strewn about in proprietary servers, collecting silicon dust.

Truth be told, the future for relational databases has really never been better — though it’s a future that’s changing rapidly, altered by the ascendency of big data and non-relational databases.

In an earlier article this week, we reviewed how and when a business should consider using non-relational (NoSQL) databases. While not comprehensive, the uses for NoSQL databases center around the acquisition of fast-growing data or data that does not easily fit within uniform structures.

(See also: When NoSQL Databases Are — Yes — Good For You And Your Company)

In describing the use cases for relational databases, it would be easy to say at this point that such databases — Oracle, SQL Server, PostgreSQL or MySQL — pretty much take care of every thing else. In the broadest sense that may be true, but that’s an overly simplistic view.

Stability Is Key

First, the easy answer: relational databases are very well-suited  for data sets that aren’t likely to suddenly expand. Even the most successful company, for instance, is not going to see its HR database (or an asset management database) grow faster than it can handle the new entries. 

One could argue, of course, that a merger with another organization that’s at or larger than your organization could result in a rapidly expanding database. But such merger and acquisitions are rare in the course of normal business, and they are usually seen coming months in advance — which, of course, gives plenty of time to merge relational data sets.

Data in such collections is also structured, meaning that once a schema for the data is defined, (length of fields, type of data for fields, etc), data doesn’t depart from that schema. Unstructured data can include weblog information, which can be highly varied in organization, depending on what’s being monitored.

The term I usually use to describe these data set to my students is “non-exploding” data, which is colorful, but fairly apt. Data will grow and change, but not beyond the normal capability for the relational database software to keep up.

Legacy Matters

Relational databases have been around for over four decades, and that means something in the IT world.

Over those years, a lot of applications have been written to manage and manipulate data that’s been held in SQL databases — some good, some bad. But if you’re considering ripping and replacing apps or data architecture, it’s important to remember that you don’t have to fix what ain’t broke.

Yes, apps can be improved, and data schemes enhanced. Better, faster databases can be installed, too. But it may not be necessary to haul your data over to a non-relational database just because it’s new and shiny. If your workflow uses structured data, is the cost of moving to non-relational systems really worth it?


My favorite use case for relational databases revolves around big data.

Yeah, you read that right: big data.

Confused? Hang on a sec. See, while it is true that rapidly changing data sets do better being stored in NoSQL databases or distributed unstructured data warehouses like Hadoop, there is still a very strong and growing need for relational databases to tap into subsets of that data to perform data analysis in a timely manner.

Time after time you can read about yet-another data vendor that’s built in hooks to the rock-star popular Hadoop, for this very reason. Hadoop is great for what it does: storing data across distributed commodity servers. But for real-time analysis? Meh. 

Better, then, to use a known relational database tool to create familiar queries to grab some of that data and crunch it that way you need to. This is a use case that’s growing very quickly these days, and which should keep relational database vendors in Dutch for the foreseeable future.

Image courtesy of Shutterstock.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.