paint-brush
NoSQL vs SQL: Comparison From the Development Teamby@tetianastoyko
1,148 reads
1,148 reads

NoSQL vs SQL: Comparison From the Development Team

by Tetiana StoykoNovember 22nd, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

There are different types of databases and thus diverse use cases for development projects. Database technology is rated on what can offer to the project and the development process. NoSQL databases are getting more attention as they are more flexible in nature. Document-oriented databases let store data as text documents. Graph databases resemble mind maps and can handle a lot of unstructured data. The most intriguing ones are graph databases. They use nodes and show the relations between them. The common practice is to use a single database to show the best use cases.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - NoSQL vs SQL: Comparison From the Development Team
Tetiana Stoyko HackerNoon profile picture

Even if you are far from the development process and data management solutions, you’ve probably heard about databases. If you imagined them as tables with data stored in columns, you’re not even that far from the truth.


Any project or web app or mobile app needs a database to store the data and easily access and manage it. However, database technology isn’t like a disorganized shelf as you won’t find the folder you need among tons of similar others.


There are different types of databases, and thus, diverse use cases for development projects.


Let’s dive into the main types of databases, their main features, and their working principles. And also development differences to be more practical.

NoSQL vs SQL databases

Essentially, we have two types: (relational) SQL and (non-relational) NoSQL databases. They in turn also divide into more subtypes. The main difference between the main two is how they operate and what data management solutions provide.


SQL databases have been longer out there and were often adopted by companies and organizations. Lately, NoSQL databases are getting more attention as they are more flexible in nature.

What are Relational Databases

SQL or Structured Query Language and databases based on it are vertically scaled and relational. What does it mean? Relational database relies on the relational model and relational algebra to operate.


All data within DB is highly structured and specified. Some see them as too strict and predetermined because they are designed in a specific way. The main benefit of SQL databases is that they are easily managed if the data has many related data points.


As it’s been on the market since the 1970s, the technology proved effective and added cool add-ons, database use cases, lifehacks, and extensions for a better user experience.

What are Non-Relational Databases

Now, NoSQL databases are horizontally scaled and don’t use the same relational model. They seem quite chaotic because of the lack of strict principles but that makes them more scalable, flexible, and convenient. While SQL databases are one type basically, NoSQL has more but 4 main ones are key-value, graph, wide-column, and document-oriented.


Key-Value Store seems to be based on association principles. For instance, each data entry is provided with a unique key value or a combination of such keys. That means that all further actions related to data, are done with these key values.


So, data entries are indexed and can be tracked by keys.


Wide-Column Store NoSQL databases store the data in wide columns. Being that obvious, the information is easily found and managed. In fact, each data entry is divided into various components, which are entered in a related column.


Document-oriented databases let store data as text documents. It may seem disorganized and overwhelming at first because every document store can consist of many objects and their descriptions.


However, the data is stored in a format, similar to JSON, thus user-friendly and simplistic.


The most intriguing ones are graph databases. They resemble mind maps and can handle a lot of unstructured data. They use nodes and show the relations between them. It looks intuitive and illustrative to grasp a lot of relations at once.


With any network-type application, graph databases will work great.

Development Team View

Database technology is a tool in the development process. That’s why they are rated on what they can offer to the project and whether are they enough to handle data. And the secret is that many apps use multiple databases at once especially if data is diverse and real-time.


The common practice is to use a single SQL and a few NoSQL databases.


The major general information is stored in SQL databases like PostgreSQL or MySQL. Although if the main storage is overloaded, it affects the app’s performance. That’s why having a few extra NoSQL databases is an efficient choice.


To better show the database use cases, let’s look at an example. Imagine we have a music streaming platform like Spotify and we need to get information about the music albums that David Gilmour wrote or took part in.


However, the guy performs independently and in a band. Now, we have two different data arrays: singer’s albums and band albums. The schematic image of popular graph database Neo4J:


Now, some code to show the difference between SQL and NoSQL approaches. If we have two data arrays, we get two different paths on how to find needed information. The first one will be an SQL database, and the second - a graph NoSQL one.


On the code level, the relational database (SQL) approach to the querying will look like this:

SELECT al.*
FROM artists a
INNER JOIN artists_albums aa ON a.id = aa.artists_id
INNER JOIN albums al ON aa.album_id = al.id
WHERE a.name = "David Gilmour"
UNION
SELECT al.*
FROM artists a
LEFT JOIN bands b ON b.id = a.band_id
LEFT JOIN bands_albums ba ON b.id = ba.band_id
INNER JOIN albums al ON aa.album_id = al.id
WHERE a.name = "David Gilmour";


Every SQL on the code level will be similar to the example above. If you want to use a NoSQL database, it needs to be set up first because the code samples may vary, depending on the database and request language used. Neo4j database with CYPHER language will look like this:

MATCH (artist:Artis {name: "David Gilmour"})
-[:BelongsTo|Releases*1...2] ->(album:Album)
RETURN artist, album;


Doesn’t it look more simple? In this case, the graph database does a better job as it’s a typical graph-theory problem. So, before using SQL and NoSQL databases, consider the amount and nature of the data you’ll handle during the project.


Combining different types is beneficial but quite resource-intensive. Sometimes using one database is enough.

Our development team had a case of combining PostgresQL, the main database with more structured management of data, with the Neo4j database (some functions needed more room).


That implies a data migration process. The first and obvious way to migrate is to save the data from Postgres as a .csv file, and later upload this file into the Neo4j database.


And another way would be to use various APIs to treat databases as sources of information and pull data with their help.

Sum Up and Final Thoughts

Database technology allows apps to function properly and store needed info. The choice of NoSQL vs SQL databases should be based on business strategy, the type and amount of data, developers’ expertise, and many more factors.


From the development perspective, the usual scenario is to have one SQL database and one or more NoSQL databases. There are many choices on the market now so try to pick with logic and all facts in the table.