Recently, I was browsing (/r/databases) on Reddit and found a blog post with the title “NOSQL – a cautionary tale“. The blog post is very well written (loved the story format) and its catchy. Initially I did not pay attention to it, but then I saw multiple comments that supported the idea of not using NoSQL; here is one such comment:
Unless a company is Netflix sized or does something very nichey and specific, I can’t see any reason to not use a regular RDBMS. They are time-tested, flexible, and it’s relatively easy to find specialists who knows it.
It is obvious that I did not agree with the author of the blog or the comment. Putting my response here for wider reach and for triggering a conversation on this topic.
Some more background
Gist of the blog post was that an engineer used a NoSQL database for managing customer sales orders. Engineer spoke to the DBA, who suggested use of a NoSQL database. Engineer went ahead and coded the application very quickly. The application was adopted and soon needed enhancements/changes. Since the data was De-normalized, application did not provide query flexibility for future extensions !!! and the application had to be re-written with SQL database. At the end author indirectly recommended using SQL over NoSQL databases.
Do you agree with the author?
My response
I tend to have a different opinion. All tools are meant for a specific purpose, yes it sounds cliché but it is true even for NoSQL databases.
For example:
- I would prefer RDBMS for *complex queries*, *transactions*, *stringent consistency requirements*
- I would prefer NoSQL/Key-Value (such as Amazon DynamoDB) for performance/scale – for user session management, user preference management…
- I would use NoSQL/Document database (such as MongoDB) over NoSQL/Key-Value for content management that requires *query flexibility*
- For the so called nichey use cases I may go with Timerseries or Graph databases
Misconception
The MOST common beginner mistake with NoSQL is exactly what is discussed in the blog post.
Assuming that NoSQL database does NOT require data modeling
Unlike relational databases there is no standard modeling practices for NoSQL databases. In order to leverage a NoSQL database effectively, you need to understand and apply modelling practices that are specific to that NoSQL database. For example to leverage Amazon DynamoDB you need to use single table modeling practices, for graph database neo4j you would use graph modeling practices…
Know your access patterns
One thing that is common to (most) NoSQL database modeling is to first identify the Access Patterns needed for your workload and then model your data/model layout such that
(a) it addresses the known access patterns
(b) offers flexibility to address future access patterns.
The reason is that there are no JOINs in the NoSQL databases 🙂 That is the one of the reasons why NoSQL databases require DeNormalization !!! BTW you can externalize the join outside of the database i.e., in the application, which has a cost (performance, complexity..).
Should I use NoSQL?
I used to be a hardcore RDBMS fan and it took me some time to deal with the anxiety of introducing data redundancy/denormalization/duplication in my DB models 🙁 Yes, I had to
(a) open up for possibilities
(b) unlearn relational concepts and
(c) educate myself.
My advice would be to:
Picking up RDBMS for all use cases is so1990’s 🙂 evaluate your persistence storage needs and then select the appropriate storage mechanism
Understand the use-case, analyze the access patterns, transactions and then decide if you would get value from NoSQL or not….pick the database that makes most sense for your workload.
Feel free to post your comments !!! believe me you won’t hurt my feelings if you disagree with me 🙂
Note: I work for a cloud company and specialize in cloud databases. Since 2019, I have seen a huge spike in adoption of NoSQL databases across our customer base. AND these customers are not just large companies but across the spectrum. In fact a number of born-in-cloud startups prefer to use NoSQL (obviously the right way).
