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.
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.