Postgres or mongo?

When I think about the question, PostgreSQL or MongoDB?, I don’t just think about databases. I think about the first time I slept under my desk during a Series A fire drill, knees crammed against the radiator, wondering whether the data schema we chose six months ago was about to bankrupt us.

You don't just pick a database. You choose a philosophy. You choose what kinds of pain you’re willing to suffer, and when.

the seductive chaos of mongo

The first time I saw MongoDB, I was charmed. It felt like jazz compared to the classical rigor of SQL. No tables, no joins, no strict schema. Just throw in your JSON and go. For a scrappy, pre-product-market-fit team, that felt like a blessing. We were iterating fast, burning cash, hiring generalists who didn’t have time to learn Postgres CTE syntax.

Mongo let us move. And in the early days, movement is everything. Startups die in stagnation, not in chaos. I’ve always believed that.

But chaos has a half-life.

MongoDB let us write flexible, messy code that worked until it didn’t. Once we had users, real users, with expectations and edge cases, we started hitting walls. Data inconsistencies crept in like mold in an old building. Query performance dipped. We were duct taping things that should have been soundproofed from day one.

One of my co-founders, let’s call him Theo, a brilliant backend mind, said something I still quote: “MongoDB is like letting your toddler decorate the living room. Looks fun, until the guests arrive.”

the cold discipline of postgres

PostgreSQL is the opposite kind of religion. It demands order, ceremony, structure. You pay the price upfront, in schemas and migrations and carefully thought-out indexes. It doesn’t coddle you with flexibility. It punishes you for guessing wrong.

But God, does it pay you back.

The second startup I ran, after the flaming wreckage of our Mongo experiment, used Postgres from day one. We were still small, still scrappy, but older, wearier. We knew where the bodies were buried from our last trip.

With Postgres, we could build a proper analytics pipeline without worrying about missing data types. Our team could reason about queries in production without tearing their hair out. Integrations with third-party tools? Dead simple. JSONB support gave us just enough flexibility when we needed to experiment, without opening the door to pure anarchy.

The catch? It slowed us down at the beginning. When the idea’s still forming, when you’re rewriting half the app every week, Postgres can feel like trying to carve your prototype out of granite. We cursed it. But we stuck with it. And we launched faster anyway, because we weren’t cleaning up messes three sprints later.

horses for courses (and founders for schemas)

Here’s the thing I’ve learned: the “right” choice depends on who you are and where you are in the journey.

Are you building a social app where data relationships are fuzzy, evolving, exploratory? Mongo might make sense, if you’ve got the discipline to layer on validation and constraints early, before they become mandatory.

Are you building a financial tool, a marketplace, or anything that smells like it will involve accounting? Don’t even blink. Postgres. Period.

I’ve seen young founders fall in love with Mongo’s freedom and end up rewriting their data layer six months before their IPO. I’ve also seen engineers waste months agonizing over perfect SQL schemas for a product that never found users.

So maybe the better question is: what kind of mistakes can you afford to make right now?

schemas and scar tissue

There’s a deeper lesson here, one I’ve learned not from tech blogs or Hacker News threads, but from scars. The database you choose becomes part of your company’s nervous system. It teaches your engineers how to think. It influences how product and engineering communicate. It shapes your tolerance for mess and your appetite for control.

And like all choices in startups, it’s not just technical, it’s emotional. It’s about trust. It’s about control. It’s about how comfortable you are living with uncertainty.

Startups are emotional machines disguised as logical engines. And that includes the architecture.

the hard truth

If you need a blanket rule, fine. Start with Postgres unless you can clearly articulate why Mongo gives you a superpower. Not convenience, advantage. If you can’t answer that, don’t kid yourself. Choose the tool that defaults to order, because chaos is coming anyway.

But if you’re experimenting in a new frontier, say, rapid AI prototyping, or building a backend for a thousand micro-apps that may never leave alpha, Mongo might give you the breathing room to stumble into brilliance.

Just know that cleanup will come...