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.
What about SQL?
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.