SQL vs NoSQL | SQL vs MongoDB

SQL vs NoSQL | SQL vs MongoDB

So, who is the winner then the more strict SQL world or the more lose NoSQL world the most important thing first there is no clear winner. It really depends on the kind of application you’re building and the kind of data you’re storing.

And in really big applications or businesses you typically use both solutions because, you work with different data or with different applications and therefore you have different needs.

Each solution has its strengths SQL, for example, uses schemas and there can be both an advantage or a disadvantage.

It’s a disadvantage if you want to be flexible about the data, but it’s an advantage if you want to have the predictable layout.

The relations also can be a huge advantage if you have data like say products and users and they are changed frequently, then it might be worse to update them in multiple collections in the NoSQL world.

If you can go for the more structured SQL approach where you only update the user in your users table and every new query which creates orders and pulls in that user information will automatically take that updated user.

Because it’s only stored and managed in one place opposed to multiple places the downside is that if you have these complex queries and you do a lot of reads that might be worse performance or might be leading to worse performance than in the NoSQL world where you will have all the data already merged in the right way in one collection.

You don’t need to merge it manually through a query data is also distributed across multiple tables in the SQL world, therefore and this can also be both an advantage or disadvantage for the reasons I just mentioned regarding their updating.

Horizontal scaling vs Vertical Scaling

We also have to talk about scaling and we can differentiate between horizontal scaling and vertical scaling. Now what’s the difference, now in both cases let’s say we have our database server if we scale horizontally we simply add more service.

We add more power by adding more service obviously, we have to ensure that our database is split up across these servers, but we still can work with it.

And that is harder than you might guess and for a SQL service it’s especially hard and often not possible because the data can’t be split across multiple servers so therefore this horizontal scaling is often very often not supported for SQL databases.

Vertical scaling then is the alternative there you simply add more power to your existing server the downside of that of course is that we’ll be some limit.

There’s only that much computing power you can add into a computer and thereafter it’ll be hard and that is indeed, one of the restrictions of a SQL database approach at some point scaling can become super hard.

Because horizontal scaling is impossible or very hard and vertical scaling has limits, now chances are that you might not hit that for your application though, because we’re talking about a lot of computing power where we face the limit but it is something to keep in mind.

NoSQL is better there because MongoDB and uber NoSQL approaches can easily be split horizontally due to the way the data is stored, that is way simpler because you have no relations, you have these standalone collections and even in one collection, you can split that data across multiple servers and then merge it together automatically.

So, horizontal scaling is possible in NoSQL, it’s not in SQL when everything we have to consider is that for SQL we have certain limitations if we have lots of and with that, I mean tens of thousands per second read and write requests.

Especially, if we have very complex queries with a lot of joins now no
SQL is schema-less and that can be an advantage since you’re more flexible, of course it can get disadvantage because you can’t rely on your record to have a certain field.

It might just not have it because there is no schema to force it to have it you also have no relations or very few relations and this is great for reading a lot.

It can be a disadvantage if you have a lot of write requests that affect multiple collections because then you have to update some data in multiple collections because you’re duplicating it instead of keeping a relation.

So, if you have data which is strongly related and which you store in multiple collections and you update that data a lot. NoSQL might not be your best solution.

Now data is typically merged or nested in a few collections and with that I don’t mean that you don’t have many collections I really just want to emphasize that you typically want to keep all the data in a collection that you query a lot.

If you got a orders page you want to put all the data in that orders collection which you need on the orders page, so that you don’t have to reach out to the products collection just to display orders and that is what I mean here. You have some collections and the amount of course varies depending on your application size. You have some collections which typically serve certain purposes.

And the idea is not to have thousands of tables which you connect with relations but instead you shrink that a bit and instead have all the data in one collection that you typically need in one part of your application.

Now I already did talk about the scaling. NoSQL can be scaled in both directions which is great of course and finally it offers a great performance for mass read and writes except for the cases where we will update a lot of collections regularly.

So if we have that user in four different collections and that user data changes all the time having to update this all the time and again we’re talking about thousands of write requests per second here can be leading towards performance than in the SQL world.

Now that was a lot of talking and finally the question remains which approach do you want to choose?

Generally you can build every application with either approach there is no clear border where you would say this has to use a SQL database or this has to use a NoSQL database.

You can build any application with Ebor database system and you’ll probably only face issues if you become really really big, at this point though as I already mentioned you typically use both systems, both approaches for different data types in your business.

So in the end you have to think about the core strengths do you want to have a clear schema? do you use a lot of relations? do you maybe work with data that changes frequently.

And is used on different parts of your application a lot, maybe you need a SQL database for that because this would allow you to manage your data exactly in that way.

NoSQL approach is great for applications where you want to read a lot maybe also write a lot, but not necessarily update thousands of places in your database in each write instead.

Maybe you got a few features in your application which are used heavily and if you our features which are not used that much and then you want to ensure that you can read all the data you want to display as quick as possible.

And  that you don’t have to run complex showing queries for that maybe scaling all the matters a lot then and therefore the horizontal scaling is a great strength.

So then you might be leaning towards the NoSQL solution, I’d say that NoSQL is a bit more hyped these days and it offers significant advantages.

But it’s wrong to say that it’s strictly better than SQL approaches and the other way around – in the end it’s always coming down to you testing playing around and simply choosing the right tool for the job you want to get done.


Leave a Reply

Your email address will not be published. Required fields are marked *