I couldn’t imagine doing anything in MongoDB or understand why that is desirable.
We have used Postgres from day 1 in March and are now 1200 people. Managing growth with a JSON blob sounds absolutely insane.
You need _more_ guarantees, not fewer.
We have used Postgres from day 1 in March and are now 1200 people. Managing growth with a JSON blob sounds absolutely insane.
You need _more_ guarantees, not fewer.
Ignorance of a technology is a poor excuse to crap on it. I've used many different technologies over my 15 year career. SQL Server, MySQL, Postgres, MongoDB, Firebase, etc. Each worked well enough, each had it's drawbacks. I'm not here to tell you MongoDB is a silver bullet for every specific use case, but from personal experience I haven't run into an instance where it was a hindrance.
Disclaimer: I currently work for MongoDB.
“I have no problem with god - it's his fan club that scares me.”
MongoDB works fine in niche situations of trying to store large blobs of JSON with extremely different elements. But for the vast majority of cases, data is highly relational. So Mongo is just a crutch that companies like because of the lower skill ceiling. Most of these startups can't be bothered to pay high enough to recruit people who payed attention during their databases lecture. In the long run, it just creates a jumbled mess of db code.
And this is a financial company.
There are cases where it's better when you're using a JSON blog inside SQL. Consider the common scenario where the pure SQL solution would be having 1 abstract model with 50 children that inherit from it, and are only each different by one or two fields.
Having one SQL model that gets queried in one way and in one place, but has 50 different JSON validators, is a lot easier to understand and work with than having 50 different SQL models that get queried in 50 different ways and places.