SQL vs NoSQL: Pros and Cons for Building a Web App

SQL databases use a defined schema for structured data. No SQL databases use a dynamic schema for unstructured or polymorphic data. But what does that actually mean? To find out, let's take a look at some live data. In my first browser tab, I have my MongoDB database. This database was created using the same source code from Lesson 4.9 from part one of the course. As you can see, each piece of data is stored as a JSON-like document. In my second browser tab, I have a Postgres database. I'll show you how to install and see your own Postgres database in the next few lessons. As you can see, data is stored in tables, much like a spreadsheet. Both databases contain the same listing data. However, in Postgres, there's a defined schema governing the shape of each listing. Let's head over to VS Code and start our node server. Currently, our server is still connected to our Mongo database. So if we execute a query for all of the listings, in our output, we'll see our entire listings collection. When we developed our server, we utilized TypeScript in our source code to define the shape of our listing data. However, it doesn't matter what technology we use in our source code, our Mongo database does not have a defined schema. So what does that mean? It means despite having a type definition in our source code, we can go over to our Mongo database and insert this into our listing. Now let's run the same GraphQL query and error. The key takeaway here is our Mongo database will accept any changes we make because it has no defined schema. If we delete that piece of garbage data, our query runs without any errors. Now try to do the same to a SQL database and we can't. That's the advantage of having a defined schema. By using a dynamic schema for unstructured or polymorphic data, our Mongo database embraces flexibility. Consider this. Imagine for some reason, going forward, instead of number of guests, I want to call this property "guests". And instead of a number, I want this property to be a string. To implement this in MongoDB, it's extremely easy because there is literally nothing we need to do. We can just start inserting data in the new format we want or update any of our existing data to the new format and MongoDB won't complain. Here in our Mongo collection, we have a mix of listing shapes. In other words, we now have polymorphic data. Remember, we are allowed to do this because of our dynamic schema. Now, we will still need to update our node server to process the new guests property, but there is nothing we need to do in our database. [BLANK_AUDIO] [BLANK_AUDIO] To achieve the same in a SQL database, we must perform a database migration. And here is an overview of the steps we will need to take. Number one, insert a new "guests" column in our table. Two, write a script to convert "num of guests" into "guests". Three, drop the old "num of guests" column from our table. And finally, four, update our server to use the new guests property. Depending on the size and complexity of a SQL database, a migration could take hours to complete. Therefore, to affect the least number of users, you will most likely want to perform this migration when your app usage is low. Flexibility is the reason why no SQL databases have become so popular in recent years, especially with startups, where they need to be flexible and agile. With that said, if you value structure modern flexibility, you just might prefer a SQL database over a no SQL database.