4 ms·

I'm a designer and front-end developer. I'm building a fullstack project by myself in Node and I'm using MongoDB. Can someone tell me why is it so bad? I've s

I'm a designer and front-end developer. I'm building a fullstack project by myself in Node and I'm using MongoDB. Can someone tell me why is it so bad? I've searched for concrete answers but I got none for the moment yet from time to time people say these kind of things and I worry.

Doxin 6y ago
These days MongoDB is mostly a subset of what SQL servers do. If all you need is a document store you can simply make a table with a JSONB column and get that. If you later discover you do need relations you can do that with e.g. Postgres but not with MongoDB. Historically MongoDB has been known for dropping or mangling data in some unfortunate ways, I'm not entirely sure what the story there is these days but personally I wouldn't trust it ever again. Data integrity is too important.
- YouthfulMarxism 6y ago
  A single point for Mongo over Postgre JsonB is WiredTiger is very good at compression. In times of Mongo:4.0 vs Postgre:10.5 it was like 20Gb vs 50Gb. Though could depend on documents structure. Not sure about current state. Querries were also somewhat faster in Mongo.
  - Doxin 6y ago
    > A single point for Mongo over Postgre JsonB is WiredTiger is very good at compression Granted, the compression story in postgres isn't currently amazing. > Querries were also somewhat faster in Mongo. If you really want fast queries it's not super hard to tune postgres to be fast and drop data if it crashes. It's a bit trickier to tune it to be quite that fast if you want to keep all your data, but for a single table of json documents it should be doable if you're okay with not having transactions.
amenod 6y ago
It's not that bad. I have used both and while I wouldn't choose MongoDB anymore, it did its job as needed. For me, the main problem with MongoDB is that it is "schemaless" - which doesn't mean that there is no schema, just that it is not explicitly stated and enforced. This leads to problems later when schema changes and you need to be extra careful not to end up with inconsistent data (good luck with that). But this is solveable, it just takes more effort than necessary. If you are using MongoDB for a small-ish project you should be ok. And if your project becomes big, you will need people who know the difference and will be able to migrate (if needed) anyway. So no worries, and good luck with your project! :)
willcipriano 6y ago
If it fits your use case it's fine, the problem is most CRUD apps don't fit into the document store use case, namely storing and only operating on exactly one document per request.
isubasinghe 6y ago
It is not bad now, I would say now it is a good key value store, which is fine, a lot of data can be modeled this way. But for relational data, PostgreSQL or MySQL will be a better choice (and I can't see this changing).
baq 6y ago
In 2021 it isn’t bad anymore, but that’s a really low bar to set. You may find that using Postgres or MySQL is easier to maintain, faster to find performance issues, quicker to fix if it breaks, etc.
diveanon 6y ago
It's not bad, its just not the best. If you are happy with your stack and it works for you that is all that matters. However, you will have a lot more features available to you by using Postgres and tools like hasura to automate your api generation. The migration from mongo to postgres isn't that bad at all, but if it ain't broke don't fix it comes to mind.
kumarvvr 6y ago
As your data complexity and relationships grow, you will end up using SQL, just that it will be in your NodeJS function calls. (Aggregating, Joins, etc) If you have highly un-related pieces of data, Mongo should be fine. But the finer point is that you can store and retrieve JSON documents very efficiently with PostgreSQL too. So, as an architect, It makes sense for me to choose PgSQL, because down the line, I have features such as relational data available without having to switch-over to other databases.

Doxin 6y ago

These days MongoDB is mostly a subset of what SQL servers do. If all you need is a document store you can simply make a table with a JSONB column and get that. If you later discover you do need relations you can do that with e.g. Postgres but not with MongoDB. Historically MongoDB has been known for dropping or mangling data in some unfortunate ways, I'm not entirely sure what the story there is these days but personally I wouldn't trust it ever again. Data integrity is too important.

YouthfulMarxism 6y ago
A single point for Mongo over Postgre JsonB is WiredTiger is very good at compression. In times of Mongo:4.0 vs Postgre:10.5 it was like 20Gb vs 50Gb. Though could depend on documents structure. Not sure about current state. Querries were also somewhat faster in Mongo.
- Doxin 6y ago
  > A single point for Mongo over Postgre JsonB is WiredTiger is very good at compression Granted, the compression story in postgres isn't currently amazing. > Querries were also somewhat faster in Mongo. If you really want fast queries it's not super hard to tune postgres to be fast and drop data if it crashes. It's a bit trickier to tune it to be quite that fast if you want to keep all your data, but for a single table of json documents it should be doable if you're okay with not having transactions.

amenod 6y ago

It's not that bad. I have used both and while I wouldn't choose MongoDB anymore, it did its job as needed. For me, the main problem with MongoDB is that it is "schemaless" - which doesn't mean that there is no schema, just that it is not explicitly stated and enforced. This leads to problems later when schema changes and you need to be extra careful not to end up with inconsistent data (good luck with that). But this is solveable, it just takes more effort than necessary. If you are using MongoDB for a small-ish project you should be ok. And if your project becomes big, you will need people who know the difference and will be able to migrate (if needed) anyway. So no worries, and good luck with your project! :)

willcipriano 6y ago

If it fits your use case it's fine, the problem is most CRUD apps don't fit into the document store use case, namely storing and only operating on exactly one document per request.

isubasinghe 6y ago

It is not bad now, I would say now it is a good key value store, which is fine, a lot of data can be modeled this way. But for relational data, PostgreSQL or MySQL will be a better choice (and I can't see this changing).

baq 6y ago

In 2021 it isn’t bad anymore, but that’s a really low bar to set. You may find that using Postgres or MySQL is easier to maintain, faster to find performance issues, quicker to fix if it breaks, etc.

diveanon 6y ago

It's not bad, its just not the best. If you are happy with your stack and it works for you that is all that matters. However, you will have a lot more features available to you by using Postgres and tools like hasura to automate your api generation. The migration from mongo to postgres isn't that bad at all, but if it ain't broke don't fix it comes to mind.

kumarvvr 6y ago

As your data complexity and relationships grow, you will end up using SQL, just that it will be in your NodeJS function calls. (Aggregating, Joins, etc) If you have highly un-related pieces of data, Mongo should be fine. But the finer point is that you can store and retrieve JSON documents very efficiently with PostgreSQL too. So, as an architect, It makes sense for me to choose PgSQL, because down the line, I have features such as relational data available without having to switch-over to other databases.