Nobody brags about their database choice two years in.
At the start it's all excitement. "MongoDB is so flexible." "Postgres handles everything." "Firebase gets us to market fast."
Fast forward 24 months. Your queries take 8 seconds. Your hosting bill tripled. Your team spends Fridays firefighting data issues instead of building features.
We've inherited enough projects to know — the database decision is where most technical debt starts. Not the frontend framework. Not the deployment setup. The database.
The Mistakes We Keep Seeing
"We picked MongoDB because schema-less felt easier."
It does. For month one.
Then your documents have 47 different shapes. Nobody knows which fields are required. Your application code is doing validation that your database should've handled from day one.
MongoDB is great for specific use cases. Event logs. Content stores. Catalogs with genuinely variable structures. But if your data has relationships — and it almost always does — you picked the wrong tool because a tutorial told you it was simpler.
"We're on Postgres but never set up indexing properly."
Postgres can handle almost anything. That's its strength and its trap.
Teams dump everything into Postgres, write queries that work fine with 10K rows, then panic when they hit 2 million. No indexes. No query optimization. No partitioning strategy. Just raw table scans burning CPU at 3am.
Postgres doesn't fail you. You fail Postgres.
"We started on Firebase and now we're stuck."
Firebase is magic for MVPs. Real-time sync. Auth built in. Hosting included. You can go from zero to demo in a weekend.
But Firebase pricing scales with reads. Your bill grows with every user interaction. And the moment you need complex queries, joins, or aggregations — you're fighting the tool instead of using it.
We've migrated three client projects off Firebase in the last year alone. Every single one wished they'd moved sooner.
"We use SQL Server because that's what we've always used."
Nothing wrong with SQL Server. Solid database. Proven at scale.
But if you're running a startup on Azure SQL with premium tier pricing because your one table has 50K rows — you're paying enterprise money for a problem Postgres solves for free.
Legacy familiarity is not a technical strategy.
The Decisions That Actually Compound
It's rarely the database engine itself. It's the decisions around it.
No migration strategy from day one. Your schema will change. If you're not set up for migrations early, every change becomes a prayer.
Mixing concerns in one database. Transactional data, analytics, search, caching — all in Postgres. It works until it doesn't. Then everything slows down together.
Ignoring read/write patterns. If your app is 90% reads and 10% writes, your architecture should reflect that. Most teams design for writes and wonder why reads are slow.
No backup testing. You have backups. Cool. Have you ever restored one? Most teams haven't. That's not a backup strategy. That's hope.
Our Take
We've built and rescued 300+ products at Qodors (www.qodors.com). The database conversation comes up in almost every project audit.
The answer is never "just use Postgres" or "just use Mongo." It's always "what does your data look like, how will it grow, and what are your access patterns?"
That question takes 30 minutes to answer properly. Skipping it costs you 6 months of refactoring later.
What To Think About Before You Pick
Five questions. Answer them honestly before you commit.
• Is your data relational or document-shaped? If things reference other things — go relational. Don't force documents to act like tables.
• What are your read/write ratios? Heavy reads? Consider read replicas or caching layers early. Don't bolt them on later.
• How fast will your data grow? If you're hitting millions of rows in year one, plan for partitioning and archiving now. Not when queries start timing out.
• What's your team's real expertise? A well-run Postgres setup beats a poorly-run MongoDB cluster every time. Pick what your team can actually maintain.
• What's your exit cost? How painful is it to migrate away if this choice doesn't work? Firebase lock-in is real. Self-hosted Postgres — you can move anywhere.
Every database works in a demo. The question is whether it works at 2am on a Friday when traffic spikes and your on-call engineer is half asleep.
Pick for that moment. Not for the tutorial.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.