Scalability in SQL and NoSQL?

Question

Post reply

Scalability in SQL and NoSQL?

Ankitdixit

SSC Enthusiast

Points: 196
More actions
March 28, 2022 at 11:07 am

#4006994

Hello All, I am working on a web application project and I want to know which database design is right from a scalability point of view between SQL and NoSQL. According to this source, SQL is vertically scalable (Add resources to increase the capacity of the existing hardware and software) and I have no idea about NoSQL. Can anyone know about this or give me any practical example?
July 26, 2022 at 9:33 am

This was removed by the editor as SPAM

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Site Owners SSC Guru Points: 80330 More actions · Answer 1

Thanks for posting your issue and hopefully someone will answer soon.

This is an automated bump to increase visibility of your question.

Grant Fritchey SSC Guru Points: 398882 More actions · Answer 2

Literally no way to really answer this question for you. Scale depends on so many different factors.

Let's look at it like this. The various different data management systems that are not relational (there isn't such a thing as a NoSQL database, there's relational which is conflated with SQL, and there's non-relational, which, even though most of them have some flavor of SQL, aren't relational, so not SQL focused or something, it's a stupid term) are focused on different kinds of data management. Usually, if we take something like MongoDB, a document database, the scalability here is focused on data collection. That means it scales by adding lots of servers. Since you only really get an ID on the document, you can put anything in there and it does it really fast. Add more servers, more speed (also, since you can add more servers locally, more local speed).

So, what do you need your data management tool to do? Text search? Don't go with SQL, get something like Splunk. Transactional data management, good gosh don't use Cassandra, get Azure SQL Database or SQL Server. Focus first on what it is you need, then determine how that can best be scaled.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Jeff Moden SSC Guru Points: 1004324 More actions · Answer 3

Grant is spot on but I'll add an "old dude's" take on it...

Which ever turns out to be the best "architecture" for your data, none of it will matter for performance if you don't write good code.

The term "good code" is highly subjective. A lot of people that claim they write good code, actually suck at it... even high profile "expert" posters that have been publishing well-intentioned articles for years and even decades. Even "official" documentation is plagued with such problems. And never blame poor performance on "a lot of rows". That normally means that you just don't know how to work with a "lot of rows. 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)