Why I Reach for MongoDB on Most Projects
A pragmatic take on choosing MongoDB for fullstack web applications — when it fits, when it doesn't, and the mistakes to avoid.
I know "use Postgres" is the internet's default advice, and for a lot of projects it's the right one. But for the kind of fullstack web applications I usually build — CRMs, invoicing tools, management systems — MongoDB keeps winning me over. Here's why.
Schemas that evolve with the product
Early-stage products change shape weekly. Postgres migrations are fine, but they add friction to the part of the cycle where friction hurts most. Mongoose schemas let me evolve the model alongside the code without a migration ceremony for every field.
The document model matches the UI
A lot of what I build is dashboards rendering nested entities — an invoice with line items, a client with contacts. In a relational store I'd join. In a document store I read one document. Less plumbing, fewer bugs.
When I wouldn't pick it
If the product is built around complex multi-entity reporting, financial transactions, or anything where "the truth" lives in relationships between tables — use Postgres. Don't let me or anyone else talk you out of it.
Takeaway
Database choice is a fit question, not a tribal one. MongoDB fits the shape of the work I do. Your project deserves the same honest evaluation.