Nearly every new project kickoff includes some version of the same question: Postgres or Mongo? The honest answer is that the decision rarely comes down to the database engine itself, and clients are sometimes surprised at how little weight we give to the performance benchmarks either side likes to publish, since at the traffic volumes most of our projects operate at, both databases are fast enough that the difference is rarely the deciding factor.
If the data is genuinely document-shaped, meaning it doesn't naturally decompose into related tables and the schema is likely to keep changing during early product discovery, Mongo removes real friction. A recent project logging inconsistent third-party webhook payloads, where the shape of the incoming data varied by event type and changed without notice whenever the third party shipped an update on their end, was a case where forcing that data into a fixed relational schema would have meant a migration every few weeks just to keep up.
Everywhere else, and that's most of our projects, Postgres's constraints, joins, and JSONB columns give us more flexibility than we expected going in, with far fewer surprises a year into a project's life. Foreign key constraints catching a bad delete before it corrupts related data, a unique constraint preventing a duplicate signup at the database level rather than relying on application code to check first, and multi-table transactions that either fully succeed or fully roll back are the kind of unglamorous features that don't show up in a feature comparison chart but save real incidents over a project's lifetime.
JSONB columns in Postgres have quietly closed most of the gap that used to justify choosing Mongo purely for schema flexibility; a Postgres table can have a handful of strict, indexed relational columns alongside a JSONB column holding a flexible blob of less-structured data, which gets you a reasonable amount of Mongo's flexibility without giving up joins or transactions for the rest of the schema. We've used this pattern on several projects where a small part of the data genuinely needed document-style flexibility but the bulk of it was clearly relational.
Team familiarity and hosting also factor in more than either database's marketing suggests. A team that's spent years writing SQL will ship a Postgres-backed feature faster and with fewer bugs than the equivalent Mongo feature, and vice versa for a team that's mostly worked in document stores. Managed hosting maturity, Amazon RDS or Google Cloud SQL for Postgres versus MongoDB Atlas, is roughly comparable at this point on both operational burden and cost, so that's rarely the tiebreaker it once was. In practice, we start most new projects assuming Postgres unless something about the data model actively argues against it, and that default has served every client well this year.