SQL or NoSQL?
Let’s see how to resolve this conundrum…
Let’s imagine a conversation between these two technologies:
SQL: Hi ,buddy! I am table-based.
NoSQL: Hey there! It seems you’re old-fashioned and too static to me. I, on the other hand, am document-based, plus I have a dynamic schema!
SQL: Oh, such a Millennial! You probably can’t help yourself because you are young. Nevertheless, I already know something about JavaScript Object Notation. But despite your snark, you should be aware that I can run complex queries in a language that is widely used by almost every developer because, as you probably know, I have been around and I have a well-known predefined schema!
NoSQL: That sounds impressive, Old Timer! But you are not as scalable as I am — I can easily scale horizontally.
SQL: Um, sorry . . . do you know what’s the meaning of ACID? Atomicity, Consistency, Isolation and Durability. Surely you don’t . . .
This conversation didn’t last forever, as they eventually decided to go together for a drink and laugh because they realized they can be very useful in different situations (and also because NoSQL just realized his name stands for “Not Only SQL”).
So have we arrived at an answer? Nope, but read on! :-)
From ancient times, when computers started roaming the planet, the primary model for database management was SQL (or relational databases). But nowadays, as technology has evolved and things have changed -we can’t always know in which direction that change may go- NoSQL databases are gaining prominence as an alternative to SQL. But why? Is it better? Why do we have to change something once it is stable?
It is because of two things: big data, and the ability to manage tons of online activity.
SQL databases are not equipped for handling “extremely” large volumes of data in the way they do (in a well-structured and organized manner). Hence, while data size goes up, its performance goes down. That’s where NoSQL comes in, as it easily scales the infrastructure for the handling a humongous amount of data (in an unstructured manner, of course!).
Additionally, NoSQL is focused to be distributable. Documents may be stored on multiple nodes, and nodes can run across multiple servers and serving data in a concurrently way — as data keeps coming, just add more hardware to keep it flowing on low-cost hardware. In contrast, SQL databases require increasing the hardware’s horsepower, which can get quite expensive. Mind you, this doesn’t mean SQL is slow because, if you anticipate a scenario, SQL’s maturity has given it a lot of support with documented material. In that situation there’s probably no reason to use NoSQL.
So we return to the question: SQL or NoSQL? I would say it depends on two things: your developer team skills and your budget. You may be thinking, “But could there be something else?” And I would say, “Sure!” In order to find you a better answer, let’s answer a few more questions:
1) Are you working with complex queries and reports?
2) Do you have a high transaction application?
3) Do you need to ensure ACID compliance? (in simple terms: do you really need a 100% of data integrity?)
If you answer “yes” to all three questions, then without a doubt you will need a SQL (relational database). But if you still feel unsure about how to answer the above questions plus you are thinking some of the below:
1) You are uncertain how your data structure is going to look in the short-term
2) Data consistency is not your top goal
3) Your data needs will only grow over time
. . . Then the answer is: You need a NoSQL solution. as its databases will ensure data won’t become the bottleneck when your applications are designed to be fast.
Computers are binaries, while human beings are not. So, in many cases (and in my personal experience), sometimes we need both, as SQL databases can be the single point of truth in your platform, while NoSQL can be your data line of defense for serving the World Wide Web.
