I kinda am on that bandwagon but at a new job we're using mongoose and mongo for our database, because the consultors that implemented the webapp before us decided so.
How do I convince mgmt that we might want to switch that? When? Is it even worth it or possible now that it's already our default?
"Just use Postgres" is advice for choosing a database for a new project, it does not apply when you're already running something else in production successfully. In general I don't think it would be worth switching unless Mongo is causing significant tangible problems in your specific environment that Postgres would solve.
From a migration perspective, the presence of JSONB fields in Postgres, and much of the modern tooling around them, mean that you can even put a highly nested document structure directly into Postgres and have a clear migration path without rewriting code.
(Do note however that Postgres' JSONB overrides the key order of objects to have canonical object identity - it thus avoids pitfall #1 in https://devblog.me/wtf-mongo but legacy code may rely on that behavior.)
MongoDB was great when it worked; I've still never experienced as fluid a workflow as Meteor enabled, where either a client update or a batch process could update a document in MongoDB and it would immediately propagate to every other interested client. RIP - while there's an active community, the Meteor team went on to do Apollo GraphQL, whose real-time support is a shadow of that original developer experience.
That said, on that same project, I can say anecdotally that I was bitten hard by some of the disaster recovery and divergent-oplog issues mentioned in the meme-y https://aphyr.com/posts/284-jepsen-mongodb - granted, the software has improved significantly since then. But I'm of the opinion that a company developing database products can only shift its internal culture so much; such a "cowboy" mentality, one that led to releasing a database product with these glossed-over problems and unreliable defaults, never truly goes away.
Rewrites always require a cost-benefit analysis. Modern MongoDB (you are running a modern version, right?) may have addressed enough concerns that it's the right decision to stick with. But even for document database needs, there's no reason not to use Postgres for green-field projects.
I think it deeply depends on how much variation in code is actually there to support the database(s). Along with how much data, how many collections, and how would you handle the migration and/or scaling with your proposed alternative? Is it worth stopping all feature development for weeks/months to migrate? How profit driven or constrained are you?
There's a lot that I like and dislike with MongoDB. As a developer, it can be a relatively nice experience. As an administrator, I hate it beyond words. It really depends on your needs, entrenchment and the skills of your staff.
Depends on your data and how it needs to be modeled and used, imo. If it’s sparse and interconnected then obviously SQL makes a lot of sense. But for data that is very document-like e.g. 10Ks you’d get from SEC EDGAR, then document based is suitable. I’ve found even with relational databases, sometimes you need to denormalize the data a bit to achieve performance benchmarks for complex queries, and there’s a tipping point where you may want to sync your data into something document-based like Elasticsearch to get improved search capabilities, too.
I kinda am on that bandwagon but at a new job we're using mongoose and mongo for our database, because the consultors that implemented the webapp before us decided so.
How do I convince mgmt that we might want to switch that? When? Is it even worth it or possible now that it's already our default?