Most developers are familiar with RDBMS's (Relational Database Management Systems) such as SQL Server, MySQL and PostgreSQL and that's because most companies that have been around for a while and have millions of records to maintain across a broad range of business requirements tend to lean towards these type of data storage mechanism. There are rows, columns, primary keys and foreign keys and data indexes galore.
But, depending on the project, you might be able to forego all of that and instead opt for a NoSQL data storage alternative instead, such as MongoDB or Redis. Here are a few reasons why you might want to make that switch on your next project.
You can read a more thorough overview of NoSQL here.
What is NoSQL?
A NoSQL database is typically a non table based storage system (unlike an RDBMS) that does not rely on a pre-determined static schema to model data. They offer alternative mechanisms for storing data, such as with JSON styled documents, key-value sets or graphs.
Each of those methods has their own unique use case and implementation as well and various vendors specialize in each. MongoDB for example relies on the document storage mechanism to store your data. You can think of these as JSON style objects that model dynamic data, instead of a tables and rows approach.
Other vendors like Redis, offer key-value styled data stores in which a particular piece of data has a key associated with it that can be used for data retrieval. These type of databases are ideal for things such as storing configuration data in which you won't require any form of complex query language.
Why would anyone want to use a NoSQL database you may wonder? Well, there's a few surprisingly reasons as to why it might be a more ideal choice for certain projects.
3. Offers flexibility
One of the hardest things to do on a relational database is to update the schema once it has been live. And often times you simply can not justify the update at all. Say for example, you have a database column for a numeric value, such as the quantity of an item. And initially, someone set the column to a datatype of string. Most relational databases will not let you update the type of that column, particularly when data has been added and indexes have been created. At least not without dropping the entire table and recreating it once again. And if the database table already has millions of records, this means that you will need to perform some kind of data transformation in the process as well.
Often times, this involves getting a DBA (Database Admin) involved and you would also end up corrupting database backups in the process as well, as the older data will not have this new schema.
Because a NoSQL database does not rely on a predetermined schema to save data, you don't have to worry about this. The power to choose a data model is essentially handed back to the developers. If a future update to the data store involves adding a new field to capture more data, that is perfectly fine and will not require any large site-wide and complex change. You simply capture the data in its new format and you won't have to make any adjustments to existing data.
This approach is ideal for agile development, in which data models can change frequently even after launch. We see alot of that with startups these days. Not being locked in to any schema really can increase the development speed overall.
2. Easier for programmers
I'll be the first to say that setting up a SQL Server database, creating the columns, creating the foreign keys, creating the indexes and then creating the DAL (Data Access Layer) is a boring task that is repetitive, but that must be done.
Usually, in a relational database, the schema has to be developed first (as mentioned above). And once it is agreed upon, the development phase begins in which case you try and code classes, objects, etc as closely as you can to the database model. Mistakes tend to happen during this phase. Often times, data types in a database don't exactly match up with the programming language that you are working with. And this is more work for developers in terms of testing and debugging to ensure data integrity.
Take a document style NoSQL database like MongoDB for example, that stores data in JSON styled objects. Because the data is already in a programming friendly format, you don't have to build any form of middleware to convert database data to client-side data, which I tend to have to do often. This is typically referred to as the Data Access Layer (DAL), and for the better part of my career as a software developer, maintaining these libraries has been a part of it.
This means that if for example your user's data is stored like the following:
{fname: 'Bob', lname: 'Smith', ID: 2342}
The data is already in a format that can be used in your code from the start. This has only really been beneficial during the past decade or so as web technologies have become more popular and as JavaScript has grown in popularity as well.
1. Smoother scalability
One of the biggest benefits of working with a NoSQL database is the fact that they are essentially designed to scale outward and not upward. What do I mean by that. Well, with a traditional SQL Server database for example, you are limited in resources based on the server itself. A database running on a particular server might only have 10GB of storage for example, and when the limits start to get reached, typically issues begin to happen.
This is where a DBA would normally step in and look for ways to increase the size of the server and then to reconfigure the database accordingly. From my experience, this typically tends to introduce the idea of downtime, in which case the application must be shut down before anything else can happen.
A NoSQL database has no such issue. Think of your typical PC right now. If you were to create a JSON file of data and save the file on the local drive, or the cloud, or a flash drive it wouldn't really matter. You can save a copy in each and you would never have to shut down your PC to do so.
It's also much more difficult overall to maintain a standard database running on a dedicated database server. You can't really, at least realistically, have a large database cloned 100 times with multiple servers across the country. At least you can't do so cheaply. And these days, serving users data through a CDN ensuring that they get a response quickly regardless of where they are is important.
This process is much more achievable on a non-relational model in which you don't have to maintain server configurations, database patches, indexes and the like. Cloning 1000 JSON like objects isn't typically a resource heavy task. You might have to wait for a sync process to complete before going live, but you won't need an instance of an expensive server running.
And that's really the biggest benefit of having a NoSQL model. The simplicity of it all makes for a much easier to maintain ecosystem of data at a much lower cost than with a heavier RDBMS configuration.
I would recommend checking out MongoDB Atlas as a good starting point for your NoSQL testing. They offer a free-tier and setup takes no more than 2 minutes.
I will close by saying that SQL databases are still important in software engineering. They have decades of work behind them along with thousands of developers that have spent careers working with them, such as myself. But with technology rapidly changing and innovating these days, it's a huge benefit to have alternatives that can fill in the gaps.