The 6 biggest myths about relational databases

Historically, relational databases have been very good — necessary in fact — for transaction processing applications. If you bought or sold something and needed to record that fact, a relational database was for you. In early days, these databases handled rows of records—with each record containing various attributes. A record might be a product sale and attributes of that sale could be price, customer, color, source, discount etc.

Thus, relational databases were limited to that very large, very important, but also extremely specific, task.

Over the last four decades, the explosive growth in the volume of data generated spurred the advent of data warehouses which gave companies a better way to aggregate and analyze that data.  

In that time the relational database has likewise evolved so that these databases now handle many different types of data, workloads, as well as different ways of storing that data. As such, modern relational databases in the cloud computing era can now handle a much more diverse set of tasks.

What was true about the category 20 years ago is no longer the case today, read on to see the biggest myths about today’s relational databases.

In the late 80s and 90s non-relational “object” databases debuted to handle data that didn’t fit well in structured, column-and-row formats. In the early 2000s XML databases, which suited document data, arrived on the market. 

Since that time, however, relational databases have adapted to handle these unstructured data types.

Modern relational databases, for example, can handle the XML format used to store many documents as well as JSON, a popular “lightweight,” readable data interchange format used in many modern applications.

Modern “converged” databases not only store but allow users to query both structured and unstructured data, thereby delivering more holistic results based on both types of information.

Myth #2: Relational databases aren’t up to the Internet of Things

The internet of things, in which multiple billions of sensors and other devices share data over the web, obviously poses a huge data management challenge. IoT devices collect and share data showing the operating status of remote machinery, as well as cellphone location data, weather stats like temperature and wind speed, and human health statistics. 

Obviously that’s a lot of data snippets from myriad sources, which in many cases needs to be processed fast. This is why in-memory database capabilities can be attractive. Storing and processing data in memory is faster than doing the same on disk, as is typically the case with relational databases. Hence the advent of a several specialized in-memory databases. But again, modern relational databases can now perform in-memory processing where needed and with the right algorithms applied. That being the case, there’s little sense in using two or more databases when one gets the job done.

In the past it was thought that relational databases were fine for big data sets as long as they didn’t get too big. That was one factor driving the early growth of distributed NoSQL (not-only SQL databases.) These databases divvied up massive data sets into separate partitions. This process, known as sharding, was not something older relational databases facilitated or handled well.

But that too, has changed. Modern relational databases can support sharding and even ensure that certain shards stay native to specific countries. That is a key requirement because some nations now require that local data stay in-country.