"Should we use Mongo or Postgres" is almost never the real question. The real question is: do you know your access patterns yet?
If you know your access patterns
Pick the database that makes your top three queries cheap and your consistency rules enforceable. Write those queries down before you choose. If they are mostly fetching one self-contained document by key, a document store fits. If they join across entities or depend on constraints and transactions, a relational database fits.
If you do not know them yet
Pick Postgres, because it forgives wrong guesses better than anything else. You can add indexes, reshape tables, introduce new relationships and even store JSON when you need flexibility, without having bet the whole data model on a guess.
Where the regrets actually come from
I have run both in production for years. The regrets never came from the database. They came from choosing before understanding what we were building.
Takeaways
- Start from access patterns, not database brands.
- Choose for your top three queries and the consistency rules you must enforce.
- When the patterns are unknown, Postgres is the safest default.
- Database regret usually comes from deciding too early, not from the database.
Building something like this?
I'm Ahmed Mamdouh, a senior full-stack & AI engineer. I reply within one working day.