SQL vs NoSQL: Key Differences
Key Points
- SQL databases are relational and require a predefined schema, while NoSQL databases are non‑relational and let you add structure later.
- SQL systems typically scale vertically by adding more CPU/Memory, whereas NoSQL platforms scale horizontally by adding additional nodes.
- Data in SQL is organized into tables with rows and explicit relationships; NoSQL stores data as flexible documents, key‑value pairs, or graph structures.
- Querying SQL relies on a fixed query language and pre‑planned joins, while NoSQL offers more dynamic, schema‑agnostic query capabilities.
- SQL excels at handling multi‑row, ACID‑compliant transactions, a strength that many NoSQL solutions do not prioritize.
Sections
- SQL vs NoSQL: Core Contrasts - A brand technical specialist outlines the primary distinctions between SQL and NoSQL databases, covering relational versus non‑relational models, schema planning effort, and the differing vertical versus horizontal scaling approaches.
- Combining SQL Transactions with NoSQL Flexibility - The speaker compares structured relational tables with transactional rollbacks to unstructured JSON‑based NoSQL, then suggests a hybrid e‑commerce design where transient session and clickstream data reside in NoSQL while finalized orders are stored in a relational database.
Full Transcript
# SQL vs NoSQL: Key Differences **Source:** [https://www.youtube.com/watch?v=Q5aTUc7c4jg](https://www.youtube.com/watch?v=Q5aTUc7c4jg) **Duration:** 00:06:04 ## Summary - SQL databases are relational and require a predefined schema, while NoSQL databases are non‑relational and let you add structure later. - SQL systems typically scale vertically by adding more CPU/Memory, whereas NoSQL platforms scale horizontally by adding additional nodes. - Data in SQL is organized into tables with rows and explicit relationships; NoSQL stores data as flexible documents, key‑value pairs, or graph structures. - Querying SQL relies on a fixed query language and pre‑planned joins, while NoSQL offers more dynamic, schema‑agnostic query capabilities. - SQL excels at handling multi‑row, ACID‑compliant transactions, a strength that many NoSQL solutions do not prioritize. ## Sections - [00:00:00](https://www.youtube.com/watch?v=Q5aTUc7c4jg&t=0s) **SQL vs NoSQL: Core Contrasts** - A brand technical specialist outlines the primary distinctions between SQL and NoSQL databases, covering relational versus non‑relational models, schema planning effort, and the differing vertical versus horizontal scaling approaches. - [00:03:29](https://www.youtube.com/watch?v=Q5aTUc7c4jg&t=209s) **Combining SQL Transactions with NoSQL Flexibility** - The speaker compares structured relational tables with transactional rollbacks to unstructured JSON‑based NoSQL, then suggests a hybrid e‑commerce design where transient session and clickstream data reside in NoSQL while finalized orders are stored in a relational database. ## Full Transcript
Hmm…SQL versus NoSQL? You'll be surprised to know that this conversation comes up
more than often than you think. Hello, my name is Jamil Spain, Brand Technical Specialist with the
U.S. Financial Services market. And as you try to pick a side on how you want to choose to use SQL
or NoSQL databases, I thought it would be great for me to bring out my top five differences to
really give you the information you want to back up your decision. So let's get started with this.
When it comes to SQL, we know that this works off a relational database structure here. Now that
means that you're going to access all your data points, they have to have some type of relation,
you've got to do a lot of pre-work to kind of decide out your structure, how they're going
to relate. Whereas on the NoSQL side this is not relational. So, we really don't have to,
I really feel for a lot of projects. I can go ahead and get started and deal with a lot of that effort
later on in the process here. As your database kinda checks, and gets a lot of traffic and needs
to really start to grow, on the infrastructure for SQL servers they're going to vertically scale.
Okay. Whereas on the NoSQL side these are going to be horizontal scaling.
All right, um and we know that SQL servers are going to be backed by this they're going
to need more memory, more computing power to actually process all these transactions. Whereas
horizontally with NoSQL it's all in memory, I can keep adding secondary nodes to handle and balance
out a lot of the usage there as well. On the SQL side when I kind of talk about my structure
it's really going to be always about table, being table based.
I am super concerned about how I’m categorizing my entities, my,
my tables into records and how I’m doing my relationship. So I have to kind of think of a, I like
to say more of a warehouse kind of nature that I’m collecting all this data here as well. And
we all know from NoSQL it is based on a document approach. So these are really going to be documents,
all right. They can be key value hashes, this is great for GraphQL, I mean a lot of the graphs, okay.
It's really meant to not really have any kind of structure, it's kind of the opposite of being
a table based I can fit pretty much anything um in this as well. So what about when you want
to access all the data? I’m going to have to use the SQL query language to actually define all my
queries to pull all my data out so it's kind of some pre-planning about how I’m going to access
and join my data if I’m going to normalize all the data there. Where I feel the NoSQL is definitely
much, much more dynamic. All right. I’m really able to, really just make my collections of these
type of documents no matter what the structure and then I can have more freedom to let it flow
and how I want to query these items as well. So lastly SQL great for multi-row transactions.
Where we have our tables, we have a lot of data that we want to put in, remember the ability to do
the transactions and being able to roll back and forth so I can really control a lot of what the,
what goes in. On the other side with NoSQL we remember that this is going to be all unstructured.
Usually it's JSON, it's very great for working with JSON. Let me make sure I write here on
number four that was also dynamic.
All right. So the unstructured JSON versus something that
is a very planned out, I specifically want to enter this in as well. So that kind of ends the
features between the two, but actually I can think of a scenario where this actually is an
"and" that should be here as well. Do we really have to make a definitive choice of either or?
One of those scenarios goes to the fact that I can have,
let's say I have a common e-commerce application which is usually composed of some bit of mobile
and has some interaction with a more of a back-end, whether it's an API that wants to kind of go
we want to commit a lot of the data. Think about a shopping cart, okay. Let's kind of visualize
this for a minute. As I make sessions, I browse, I do all these things, it's more like data in
transient it's not really ready to be committed yet. So, I could see unstructured session data,
product data, what I clicked on set of clicks all that stuff could be great for compiling into any
structure into a NoSQL site. And then as I make the order or the transaction that could be definitely
something that I kick off into my SQL database back in where I want to facilitate interaction
with different departments, not only is it going to the shipping department, maybe the marketing,
maybe a couple other subsystems that I want to document that order has been placed and kick off
a few other work streams. So, this is just one of many scenarios that you can choose.
I'll be curious to know in the future whether you pick a side, or you join forces to power your next
application. Thank you for your time. If you have questions, please drop us a line
below. And if you want to see more videos like this in the future, please like and subscribe.