For 95% of the use cases I'd recommend an RDBMS (SQL) such as MySQL or PostgreSQL rather than MongoDB - easier to use, more powerful, and just a better choice. Whether it should be MySQL or PostgreSQL is in my opinion a toss-up, I mostly used MySQL but PostgreSQL is also fine.
MongoDB is really for niche uses cases, those where you need to stash away vast amounts of fairly simple data - think IoT, weather data, any sort of large scale real time data collection - that's where MongoDB shines, not for your average web app. And for apps/systems that need huge scalability beyond the capacity of RDBMS, but then you're really talking huge scale.
But for your typical run-of-the-mill web/business apps, MongoDB would in general be a poor choice. The lack of a standardized and powerful query language like SQL, with its joins, aggregations and so on, the lack of a schema, and the lack of transactions (ACID), makes MongoDB much harder to use. With MongoDB (NoSQL) you will constantly be reaching for tricks and hacks which will make your app harder to develop, and maintain.
This! People mindlessly go for MongoDB because of NoSQL hype, not understanding the real use case for these kind of databases. I was one of them. Maintaining "a typical app" was a real pain in the ass. Moved to PostgreSQL fixed all the issues and removed a lot of code hacks from the codebase.
Mostly, with NoSQL you can't assure any kind of data integrity - everything needs to be based on your app's code. There are no relationships in NoSQL unless you code it yourself - I think that's the main pain for me and it's very, very fragile.
Indeed, most RDBMS enforces integrity very well, and it would be counter-intuitive to store denormalized / JSON data. Actually, graph-type NoSQL can do this as well (as well as being ACID compliant).
BTW, how do you balance between ORM features vs true SQL features?
100% agree with this. I'm loving working with postgres and I was a firestore user for a long time.
BUT just so the facts are right, mongodb does support ACID transactions. Also when u pair mongoDB with mongoose you can manage your collections with schemas in an OKish way.
You're right, more recent versions of MongoDB do have ACID, they've added that. And I've used mongoose as well, yes that's an improvement because you can declare schemas.
Anyway, I think how it often goes is that a dev starts with a simple app, with a very simple data model, and then MongoDB looks great, but later on when they expand it and the data model becomes more complex they will often think "I wish I'd had chosen an RDBMS" ;-)
But interestingly it's not per se an "either or" choice - it is possible to combine SQL and NoSQL (two databases in one app), for instance you could manage your users and stuff like that in a SQL database, while you store large amounts of "unstructured" data (text, images, video etcetera) in MongoDB. Perfectly possible and I think there are use cases where it might make sense.
Hmm, ok. I agree that Mongodb is great for some cases, but I've heard that SQL is good for certain cases as well. But they also scale better than monogdb(so I've heard), which is what I'm looking for. I'm going to make a social media app, but I want it to be able to scale easily if needed.
So for this case would you say to use a SQL database?
"... they also scale better than mongodb ... which is what I'm looking for"
Eh no, it's the other way around actually - NoSQL databases (like Mongo) potentially scale better than SQL databases (RDBMS) ... with NoSQL you can scale out "horizontally" (using 'shards' on different machines), with SQL databases there are limitations in that regard - conventionally a SQL database has to run on one big fat machine.
So if it's really all about extreme scalability for you, then MongoDB would be your choice. I'd say SQL databases are better/easier than NoSQL in almost all respects (ease of use, powerful query language with joins, normalized data model, defined schema, ACID), except for scalability - that's where NoSQL shines - at least in theory :-)
But, we're talking about giga scale here ... will your social app really be that huge? You're not going to build a new Facebook or are you :-)
What stack (backend) are you gonna use, node/express or something else? Social media app, you need streams/channels for realtime ... I'm thinking GraphQL and all that ... Prisma? prisma.io which supports PostgreSQL and MySQL. But yeah "social media" = "big amounts of non structured data" (text, images, audio/video)" means MongoDB does sound like a good fit.
Yeah, I'm thinking node/express, and graphql. Never heard of prisma though. And yeah, I guess mongdb is good, so I'll go with that! Thanks for all the info and help >:)
Mongo is a good choice if you have an app where (a) you don't have an extensive data model with lots of relations/joins (like an accounting system, or other "line of business" apps), and (b) you need to store lots of unstructured data like text, images, video/audio and so on.
So your social media app fits the bill, while I'd never ever try to develop an accounting app with Mongo as the data store :-)
For 95% of the use cases I'd recommend an RDBMS (SQL) such as MySQL or PostgreSQL rather than MongoDB - easier to use, more powerful, and just a better choice. Whether it should be MySQL or PostgreSQL is in my opinion a toss-up, I mostly used MySQL but PostgreSQL is also fine.
MongoDB is really for niche uses cases, those where you need to stash away vast amounts of fairly simple data - think IoT, weather data, any sort of large scale real time data collection - that's where MongoDB shines, not for your average web app. And for apps/systems that need huge scalability beyond the capacity of RDBMS, but then you're really talking huge scale.
But for your typical run-of-the-mill web/business apps, MongoDB would in general be a poor choice. The lack of a standardized and powerful query language like SQL, with its joins, aggregations and so on, the lack of a schema, and the lack of transactions (ACID), makes MongoDB much harder to use. With MongoDB (NoSQL) you will constantly be reaching for tricks and hacks which will make your app harder to develop, and maintain.
This! People mindlessly go for MongoDB because of NoSQL hype, not understanding the real use case for these kind of databases. I was one of them. Maintaining "a typical app" was a real pain in the ass. Moved to PostgreSQL fixed all the issues and removed a lot of code hacks from the codebase.
No, I was there because of the lower cost of entry.
Of course, I know that RDBMS's TRIGGER and FOREIGN KEYs can be convenient.
Also, I don't hate RDBMS, but the language (SQL) itself.
Indeed, if you can explain more...
Mostly, with NoSQL you can't assure any kind of data integrity - everything needs to be based on your app's code. There are no relationships in NoSQL unless you code it yourself - I think that's the main pain for me and it's very, very fragile.
Indeed, most RDBMS enforces integrity very well, and it would be counter-intuitive to store denormalized / JSON data. Actually, graph-type NoSQL can do this as well (as well as being ACID compliant).
BTW, how do you balance between ORM features vs true SQL features?
95% is a bit low IMO
Haha yes probably more like 98-99% ;-)
100% agree with this. I'm loving working with postgres and I was a firestore user for a long time.
BUT just so the facts are right, mongodb does support ACID transactions. Also when u pair mongoDB with mongoose you can manage your collections with schemas in an OKish way.
You're right, more recent versions of MongoDB do have ACID, they've added that. And I've used mongoose as well, yes that's an improvement because you can declare schemas.
Anyway, I think how it often goes is that a dev starts with a simple app, with a very simple data model, and then MongoDB looks great, but later on when they expand it and the data model becomes more complex they will often think "I wish I'd had chosen an RDBMS" ;-)
But interestingly it's not per se an "either or" choice - it is possible to combine SQL and NoSQL (two databases in one app), for instance you could manage your users and stuff like that in a SQL database, while you store large amounts of "unstructured" data (text, images, video etcetera) in MongoDB. Perfectly possible and I think there are use cases where it might make sense.
Hmm, ok. I agree that Mongodb is great for some cases, but I've heard that SQL is good for certain cases as well. But they also scale better than monogdb(so I've heard), which is what I'm looking for. I'm going to make a social media app, but I want it to be able to scale easily if needed.
So for this case would you say to use a SQL database?
"... they also scale better than mongodb ... which is what I'm looking for"
Eh no, it's the other way around actually - NoSQL databases (like Mongo) potentially scale better than SQL databases (RDBMS) ... with NoSQL you can scale out "horizontally" (using 'shards' on different machines), with SQL databases there are limitations in that regard - conventionally a SQL database has to run on one big fat machine.
So if it's really all about extreme scalability for you, then MongoDB would be your choice. I'd say SQL databases are better/easier than NoSQL in almost all respects (ease of use, powerful query language with joins, normalized data model, defined schema, ACID), except for scalability - that's where NoSQL shines - at least in theory :-)
But, we're talking about giga scale here ... will your social app really be that huge? You're not going to build a new Facebook or are you :-)
Oh, I guess I got them mixed up lol.
No, I don't think so, but I'm partly wondering which kind of database is better, and partly planning ahead.
Probably not, but that would be cool :D
So you think mongdb is a good choice?
What stack (backend) are you gonna use, node/express or something else? Social media app, you need streams/channels for realtime ... I'm thinking GraphQL and all that ... Prisma? prisma.io which supports PostgreSQL and MySQL. But yeah "social media" = "big amounts of non structured data" (text, images, audio/video)" means MongoDB does sound like a good fit.
Yeah, I'm thinking node/express, and graphql. Never heard of prisma though. And yeah, I guess mongdb is good, so I'll go with that! Thanks for all the info and help >:)
Mongo is a good choice if you have an app where (a) you don't have an extensive data model with lots of relations/joins (like an accounting system, or other "line of business" apps), and (b) you need to store lots of unstructured data like text, images, video/audio and so on.
So your social media app fits the bill, while I'd never ever try to develop an accounting app with Mongo as the data store :-)
Ok, good to know. Thanks!