Why Relational Databases Aren’t Always Enough

relational databases are powerful tools.

since the 80s, they have been the power-horse of most software applications and continue to do so today. relational databases (rdbms) were initially designed to codify paper forms and tabular structures, and they do that exceedingly well. for the right use case and the right architecture, they are one of the best tools for storing and organizing data.

because relational databases store highly structured data in tables with predetermined columns and many rows of the same type of information, they require developers and applications to strictly structure the data used in their applications.

but today’s user requirements and applications are asking for more . more features, more data, more agility, more speed and–most importantly–more connections.

in this rdbms & graphs blog series, we’ll explore how relational databases compare to their graph database counterparts, including data models, query languages, deployment paradigms and more.

this week, we’ll discuss why relational databases aren’t a good fit for connected data use cases.

why we’re writing this blog series

to begin, let’s be clear about why we’re writing this blog series.

first things first: we didn’t write this series to bash relational databases or to criticize a still-valuable technology. without relational databases, many of today’s most mission-critical applications wouldn’t run, and without the early innovation of rdbms pioneers, we would have never gotten to where we are with today’s database technology.

rather, we wrote this series to introduce you–likely a developer with rdbms experience–to a database technology that changed not only how we see the world, but how we see the future being built . today’s business and user requirements demand applications that connect more and more of the world’s data, yet still expect high-levels of performance and data reliability.

we believe those applications of the future will be built using graph databases, and we don’t want you to be left behind. in fact, we’re here to help you through every step of the learning process.

while other nosql (not only sql) databases advertise themselves with in-your-face defiance of rdbms technology, we prefer to be a helpful resource in helping you add graph databases to your professional skillset–no matter whether graphs are a replacement of or a complement to your rdbms.

relational databases still have their perfect use cases. but for those cases when you need a different solution, we hope this series helps you recognize when–and how–to use a graph database to tackle those new challenges.

the mismatch between relational databases and data relationships

despite their name, relational databases are not well-suited for today’s highly connected data, because they don’t robustly store relationships between data elements .

(it’s worth noting that relational databases take their name from the highly specific mathematical notion of a "relation"–aka a table–as part of e.f. codd’s . the name does not derive from describing relationships between data.)

traditionally, developers have been taught to store data in the columns and rows of a relational model. yet, columns and rows aren’t really how data exists in the real world. rather, data exists as objects and the relationships between those different objects.

these types of complex, real-world data are increasing in volume, velocity, and variety . as a result, data relationships–which are often more valuable than the data itself–are growing at an even faster rate.

the problem: relational databases aren’t designed to capture this rich relationship information.

the bottom line: applications (and the enterprises that create them) are missing out on critical connections essential for today’s high-stakes, data-driven decisions.

the agile realities of today’s software applications

every development team faces the reality of ever-changing business and user requirements that call for frequent modifications and pivots to a given data architecture.

database administrators (dbas) and developers face a steady stream of business requests to add elements or attributes to meet new requirements–such as storing information about the latest social platform–but such regular schema changes are problematic for rdbms developers and come with a high maintenance cost.

that’s because relational databases don’t adapt well to change. rather, their fixed schema works best for problems that are well-defined at the outset.

slow and expensive schema redesigns also hurt the agile software development process by hindering your team’s ability to innovate quickly–a significant opportunity cost no matter the size of your bottom line.

the verdict: relational databases aren’t engineered for the speed of business agility.

how connected data queries cripple rdbms performance

despite advances in computing, faster processors, and high-speed networks, the performance of some relational database applications continues to slow. this performance slump has several known symptoms , but the root cause usually boils down to one factor: queries about data relationships.

since relational databases aren’t built or optimized to handle connected data, any attempt to answer data relationship queries–such as a recommendation engine , a fraud detection pattern , or a social graph –involves numerous joins between database tables.

in relational databases, references to other rows and tables are indicated by referring to their primary-key attributes via foreign-key columns. (see below for an example.)

a join table between the persons and departments tables in a relational database using foreign key constraints.

these references are enforceable with constraints, but only when the reference is never optional. joins are then computed at query time by matching primary and foreign-keys of the many (potentially indexed) rows of the to-be-joined tables. these operations are compute and memory-intensive and have an exponential cost as queries grow.

consequently, modeling and storing connected data becomes impossible without extreme complexity. that complexity surfaces in cases like sql statements that require dozens of lines of code just to accomplish simple operations. overall performance also degrades from query complexity, the number and levels of data relationships and the overall size of the database.

with today’s real-time, always-on expectations of software applications, traditional relational databases are simply inappropriate whenever data relationships are key to success.

an alternative (or addition) to relational databases

as previously mentioned, relational databases have their appropriate use cases. for highly structured, predetermined schemas, an rdbms is the perfect tool.

but as we’ve seen, relational databases aren’t always enough. applications that require connected data insights can’t rely on the relational model alone.

while relational databases sometimes need to be replaced entirely, often the rdbms solution can’t (or doesn’t need to) be shut down. in these cases, developers and architects can use a polyglot persistence approach–using different databases for their best-of-breed strengths.

so whether you’re replacing your rdbms or just complementing it with another data store, the volume, velocity, and variety of today’s data–and data relationships–requires a solution that’s engineered from the ground up to store and organize connected data.

next week, we’ll meet that solution: graph databases.