1. Speed: NoSQL is way faster than SQL for most access
2. Ease: Dev time is lower as the data is kept in the way you'll use it, not in relational tables - skip the ORM, skip the db migrations, etc.
3. You need NoSQL at scale anyway: As the sole db of an app, NoSQL isn't ideal at scale because of data duplication and storage size. But when/if you need to add SQL you probably still keep the NoSQL too for the faster access, storing temp data, etc. Most companies use both SQL and NoSQL.
Scenario:
Imagine an API for a video game that fetches data for an Auction House type feature. If every single time your millions of players were running SQL queries, it would be an incredibly slow and expensive feature. Much better to have that data cached in a NoSQL layer so people can access it quickly/concurrently, and only periodically hit SQL to populate out NoSQL caches. Could also use an ORM with SQL, or another in-memory solution, but NoSQL is nice if there are many nodes or maybe due to your cloud setup you can't run it in memory.
Really is not a "SQL vs NoSQL" you use both for different things. To me at this point it doesn't matter if someone "starts with" SQL or NoSQL, in almost all cases I would use both eventually. For hobby projects, even a slight preference toward NoSQL for ease of use and data flexibility, but getting into subjective territory. Sequelize is just as cool/easy
Do you have a source about the 10x speed gain for NoSQL? It doesn’t really make sense to me and the benchmarks I found say it’s about the same, which makes sense to me.
They're also backed by the CIA lol. To your point, I should have said "NoSQL" not "MongoDB" per se. I took the question to mean "Why not SQL" but they could very well be asking "Why not another NoSQL"
1. Speed: NoSQL is way faster than SQL for most access
2. Ease: Dev time is lower as the data is kept in the way you'll use it, not in relational tables - skip the ORM, skip the db migrations, etc.
3. You need NoSQL at scale anyway: As the sole db of an app, NoSQL isn't ideal at scale because of data duplication and storage size. But when/if you need to add SQL you probably still keep the NoSQL too for the faster access, storing temp data, etc. Most companies use both SQL and NoSQL.
Scenario:
Imagine an API for a video game that fetches data for an Auction House type feature. If every single time your millions of players were running SQL queries, it would be an incredibly slow and expensive feature. Much better to have that data cached in a NoSQL layer so people can access it quickly/concurrently, and only periodically hit SQL to populate out NoSQL caches. Could also use an ORM with SQL, or another in-memory solution, but NoSQL is nice if there are many nodes or maybe due to your cloud setup you can't run it in memory.
Really is not a "SQL vs NoSQL" you use both for different things. To me at this point it doesn't matter if someone "starts with" SQL or NoSQL, in almost all cases I would use both eventually. For hobby projects, even a slight preference toward NoSQL for ease of use and data flexibility, but getting into subjective territory. Sequelize is just as cool/easy