I have seen a few posts about people saying their favorite database and I am curious now why you might choose a NoSQL database over an SQL database or vice versa.
Personally, for basically every project, I choose to use DyanmoDB. There are a few reasons why but they all in a way boil down to cost and performance.
As far as the cost side DynamoDB offers an extremely generous free tier and I have never on my side projects reached passed the free tier capacity which is really nice. One of the said side projects I had 10,000 users and even with doing roughly 150 reads a second it was free.
Another aspect I love about Dynamo is how good it works with serverless because you never make a constant connecting with the database, every change is done through HTTP requests. Dynamo is also extremely performant no matter how high you scale it. Currently working with a client that wanted to switch off of Postgres to Dynamo and performance has been an insane improvement for them.
I feel one of the main reasons I do not choose an SQL database is because I do not really have any analytical reads or have access patterns that I do not know about. I think SQL performs best when you need those analytical type queries but it seems a lot of people prefer SQL databases over NoSQL and was curious to see the reasoning.
Top comments (5)
Hi Garret, this is an evergreen and always interesting topic.
My opinion is that it really depends on which type of application you're trying to build and which pattern of data access you'll have. If the data model is documents I think a document DB is fine. If the data model is highly relational, you're probably better of with a RDBMS.
This is an interesting journey in the other direction:
Why we Moved From NoSQL MongoDB to PostgreSQL
Pavan Belagatti ・ Apr 24 '18 ・ 5 min read
From reading that it just seems there are 2 reasons you did not like MongoDB. One because you could not figure out how to model the data in a way to query at good speeds. Two because you could not add new fields easily.
I will admit point one is a bit hard because trying to model data in NoSQL is not as easy in SQL. SQL is all based on trying to normalize data and put data into as many tables as possible whereas NoSQL you denormalize all your data into one table.
For point 2 it's just as simple as running a script to add a field with a default to every document where necessary so maybe a small inconvenience it is not built-in, but creating a small script to do this is super easy to do so I do not see much of a problem here.
I personally have no used MongoDB much so I am not sure exactly how to model data in MongoDB as it does vary for each NoSQL variant (which again is annoying and can make it hard). However, using NoSQL is extremely performant (at scale NoSQL is more performant smaller apps may be the other way around) compared to SQL because of the fact you build NoSQL for queries and not for the data that is in them.
Of course, there still is some cases like analytics that are better for SQL where you may have an extreme variety of access patterns that makes it really hard to build in specific queries for the data as with analytics there are so many access patterns that are possible in that it can be impossible to know every single pattern.
I think you agree with me, it depends on the use case ;-)
ps. I'm not the author of the article :D
Ah whoops thought you wrote that article haha did not pay attention to that part fully obviously. Yeah, it for sure depends on use case.
Yes agreed it depends on the use case! You might find this article on DB architectures and use cases interesting as well.