The Future of Relational Databases

NoSQL is all the rage, and many people are considering a move to NoSQL database systems. Database users sense that relational database systems are yesterday’s technology and NoSQL is the future. They look at high-volume websites embracing NoSQL and assume these companies are at the forefront of a new wave of database adoption. However, there are many flaws in this logic.

First, NoSQL is not a single technology. Specifically, it is an anti-technology: Any database technology that does not use the SQL query language can be called NoSQL. In fact, modern NoSQL databases represent four different technology groups: key-value stores, document databases, column stores, and graph databases. You can’t just pick NoSQL technology – you must decide which NoSQL technology to use.

Second, many high-volume websites have chosen to use NoSQL so it must be better for everyone, right? Well, not necessarily. High-volume websites have atypical scaling requirements, and are willing to spend more on software development to achieve this scaling. Is that your organization? Probably not.

SQL has been around as a standard for 25 years; it has wide industry adoption and sophisticated tooling to enable high productivity. SQL has been the bread-and-butter of the database world for decades, giving organizations a flexible, standard interface to access their data. NoSQL technologies grew out of the need to scale without the overhead of SQL, but such scale comes at a cost – often a big cost. NoSQL systems often lack the flexibility, administrative ease, and development productivity of SQL systems. If you are a big organization and need massive scale, you might be willing to pay those costs, but what about typical companies?

For example, depending on the NoSQL database you choose, you might get better performance, better write scaling, or a database language that more closely matches your application language. However, the database language might be less expressive or flexible, or the NoSQL database might lack concurrency or durability guarantees. Are you prepared to write a program to get a report from your database? Are you willing to use a more limited set of languages to access your data?

Many NoSQL databases do not provide ACID guarantees, for performance and scaling reasons. That might be fine for your workload; but if it is not, you will have to code concurrency and durability handling into your application or middleware. Implementing these can be complex and difficult to test.

Threats to SQL database dominance are not new. Object databases were touted in the 1990s as a way to store data in a format that more naturally fits object-oriented languages. Unfortunately, object databases were too closely tied to specific object-oriented languages, making it difficult to access data in a flexible way. Object databases soon lost favor, and object-relational mappers gained popularity.

A decade later, XML databases were all the rage, giving flexible storage for XML-based applications. Relational systems soon embraced XML storage, and pure XML databases faded as well.

NoSQL databases will never go away, just like object databases and XML databases are still around, but SQL databases will adapt. SQL databases are again learning from those dissatisfied with SQL’s limitations, and are adding features to fill the gap that motivates NoSQL adoption.

Postgres has added many NoSQL-like features that allow greater scaling, non-durable storage, and JSON data manipulation – allowing users to get NoSQL features while retaining the benefits of SQL relational systems.

So, if you are considering NoSQL, you have a choice: Choose NoSQL and accept its limitations, or keep SQL and get NoSQL features with modern SQL databases like Postgres.