In part 1 of this series of blog posts, we talked about how the choice between NoSQL and SQL databases is bound to the core design of the application and I promised to get deeper into what this means. We started by looking into how support for a flexible schema is both advantageous and challenging. In this post, I will discuss CAP theorem and explain how it affects both the choice of the database technology and the application logic. Understanding CAP theorem and its implications is very important in designing a distributed system.
When choosing the database technology for an application, the most important question is whether to stick with the good old SQL databases, or follow the trend and choose NoSQL. The answer to this question is not as easy as the names (SQL or not) suggest. There are lots of checklists out there trying to help you make the right choice, and they are very helpful for quickly shaping our minds around the topic. However, in my experience, this is more than a checklist topic, rather you need a deep understanding of both technologies. If you are from same era as I am, you have received education or gained experience with SQL databases, probably with none or little knowledge of NoSQL databases. For us, data manipulation and storage have always been tied to relational models, until we heard about the seemingly opposite word of NoSQL. It is just natural to first grasp the new concept in the same light as the old model with supposedly the biggest difference to be ‘not having strict schema’, which sounds just like what we needed. However, there is a lot more to it. We need to dive beyond the shape of stored data or the retrieval options such as ‘to JOIN or not’.