I think post the addition of JSONB to PostgreSQL (and the even more recent addition of full text search for json fields) there are fewer reasons to choose MongoDB on day one for most web apps. As now one can combine structured data to unstructured data, the flexibility of PostgreSQL has increased quite a lot. The syntax isn't great, but you can use functions to improve it a bit.
That doesn't mean that MongoDB doesn't have its place, but I've read (and heard one or two from first account) so many bad or even horror stories about it that I'm starting to think there is some thruth to them. It's also true that many of these stories tend to be applicable to older versions of MongoDB, so they might not still be relevant.
Still, having to lose data because of the DB and not because of a mistake made by the app developers is quite bad.
PostgreSQL isn't perfect but 25 years of open source DBMS count for something. It's rock solid. Joining data is highly optimized, it can be done in parallel, you can use foreign data wrappers to import all sort of data and use its basic pub/sub technology to spit out data automatically. The industry around it it's quite big and recently Microsoft acquired Citus which is a well known sharding solution to overcome the PostgreSQL limits on scaling out.
The only few times I had to use MongoDB were for internal prototypes, in situations where nobody wanted to think about the schema of the data and start iterating so we choose something that flexible. It's probably bit of a common strategy if you work in agency which churns out apps one after the other. In none of those cases the final app ended up in MongoDB though, they were all converted to either MySQL or PostgreSQL, depending on the client.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think post the addition of
JSONBto PostgreSQL (and the even more recent addition of full text search for json fields) there are fewer reasons to choose MongoDB on day one for most web apps. As now one can combine structured data to unstructured data, the flexibility of PostgreSQL has increased quite a lot. The syntax isn't great, but you can use functions to improve it a bit.That doesn't mean that MongoDB doesn't have its place, but I've read (and heard one or two from first account) so many bad or even horror stories about it that I'm starting to think there is some thruth to them. It's also true that many of these stories tend to be applicable to older versions of MongoDB, so they might not still be relevant.
Still, having to lose data because of the DB and not because of a mistake made by the app developers is quite bad.
PostgreSQL isn't perfect but 25 years of open source DBMS count for something. It's rock solid. Joining data is highly optimized, it can be done in parallel, you can use foreign data wrappers to import all sort of data and use its basic pub/sub technology to spit out data automatically. The industry around it it's quite big and recently Microsoft acquired Citus which is a well known sharding solution to overcome the PostgreSQL limits on scaling out.
The only few times I had to use MongoDB were for internal prototypes, in situations where nobody wanted to think about the schema of the data and start iterating so we choose something that flexible. It's probably bit of a common strategy if you work in agency which churns out apps one after the other. In none of those cases the final app ended up in MongoDB though, they were all converted to either MySQL or PostgreSQL, depending on the client.