Onyekachukwu Chukwuka
A Lead Engineer and Solutions Architect with deep expertise in Java, Kotlin, Scala, Python and cloud services. He designs scalable, secure systems and architects resilient solutions, blending hands-on leadership with strategic vision to solve complex challenges and drive impactful digital transformation across industries.
Article by Gigson Expert
A Quick Story
So, something interesting happened this past Sunday. A friend of mine came over on Saturday and decided to crash at my place. Then on Sunday morning, a mutual friend of ours who lives close by invited him to church. Somehow, I got dragged into the plan too.
Well, I think he did plan for church because he came ready with a really nice native wear. Perfect for Sunday service. Me?
I couldn’t sit that one out, so I pulled out one of my own “never-been-worn” natives. You know that outfit you keep saving for the right moment? Yeah, one of those. We stepped out looking good to meet up with our other friend and his wife.
First shocker: They were dressed like extras from Peaky Blinders - sharp suits, ties, jackets. Meanwhile, we were in our elegant but understated native wear. They were looking like fashion week. We looked more like Sunday service😏.
Turns out, it was the church’s 13th anniversary, and there was a dress code: suits, ties, proper formalwear. By the time we got to church, it was clear: uniformity has beauty.
The entire church was in sync. My friend and I? We stood out, but not in a way we would’ve preferred. If there were to be any group photo, we’d be behind the cameras. We looked good, but not quite right. You know how you didn't do anything wrong, but also didn’t do anything right. The difference was subtly obvious. We didn’t FIT.
We learned the hard way that looking good isn’t the same as fitting in. Same with databases in 2025.
You see, you can have a powerful service, great infrastructure, even a very “serious” and robust database setup, and still be wrong. If you:
- Use a relational DB for fast-changing, flexible documents,
- Or pick a NoSQL store when you actually need strict joins and transactions,
- Or try to run analytics and real-time ops on the same DB,
…it’s agbada-at-a-suit-coded-service all over again. Perfect build. Perfect tech. Wrong fit.
Let’s talk about how to pick the right database for your next project.
Choosing the right database.
Choosing the right database engine in 2025 is like choosing the right outfit for an event. Different occasions demand different styles, and showing up in the wrong one can leave you underdressed, overdressed, or just plain uncomfortable. Before committing to a database engine, you need to answer two core questions:
- What kind of data are we working with?
- How do we intend to store and access it?
A clear and honest answer to these questions will ordinarily guide you towards either:
- SQL (e.g., PostgreSQL, MySQL,...), or
- NoSQL (e.g. MongoDB,...)
What Types of Data Are We Modeling?
Data typically falls into two main buckets:
Structured Data
- Well-defined schema
- Relationships between entities
- Best fit: Relational databases (SQL)
- Examples: Users, Orders, Products
Unstructured / Semi-structured Data
- Flexible, schema-less, nested documents
- Best fit: NoSQL databases
- Examples: User-generated content, social feeds, logs
How do we want to store data
Relational databases (Postgres and MySQL).
With Relational (or SQL) databases, data is stored in tables made up of rows and columns.
Example: For a simple e-commerce app, we might have:
- users table
- orders table
- order_items table
With each table having a defined and fixed schema. Relational databases are well-suited for structured data, particularly when relationships matter (e.g., users → orders → items), and they enforce constraints. While schema changes in SQL require migrations, modern tooling like Prisma, Flyway, and Liquibase make this easier. They’re also not as easy and natural to deal with when your data is messy, nested, or constantly changing.
Non-Relational databases (MongoDB).
Let’s step away from the tabular structure into a more flexible schema. With Non-Relational (or no-SQL) databases, data can be stored as documents (JSON/BSON), key-value pairs, graphs, etc. This is a good fit for when your data doesn’t fit neatly into rows and columns. It is also great for nested / JSON-heavy data.
MongoDB is a variation of a NoSQL database that stores data as JSON-like documents inside collections. Same general attributes apply here: No fixed schema, meaning two users can have different fields, and new fields can be added on the fly without downtime.
To keep our data consistent or to manage complex analytics, we have to do more work than we ordinarily would have with a SQL database. Also, enforcing strict rules is harder here.
How do we intend to retrieve data
Relational Databases(PostgreSQL & MySQL)
Both use SQL, the classic query language.
Why this is nice:
- SQL is powerful and standard.
- Easy to do complex stuff: joins, aggregates, reports.
- Tons of tools and libraries support SQL out of the box.
Postgres generally has more advanced SQL features (window functions, JSON queries, extensions, etc.), while MySQL covers the basics really well and is usually simpler to get started with.
Non-Relational databases (MongoDB).
MongoDB uses objects that look like JSON for queries. It’s more like calling functions in code than writing SQL.
Feels nice when:
- You’re already working with JSON in your app.
- Your data lives mostly in a single document (a few joins).
But deep, complex reporting can become harder to express than a single SQL query
Performance & Scaling (very simplified)
To be very honest, all three can be fast enough if your app is small to medium, and if you design with optimization in mind (indexes and all). The difference shows mostly when you’re at a serious scale or doing some complex analytics. Let’s zoom in a bit for the sake of comparison.
PostgreSQL
- Strong at very complex queries.
- Good for systems with mixed reads/writes and lots of business logic.
- Great when you need “serious” transactional behaviour and analytical queries.
- Vertical scaling (bigger server) is common however Citus, Timescale, Supabase, Neon, AlloyDB, Aurora Postgres all make horizontal scaling trivial or fully managed.
- Postgres now has excellent JSON/JSONB support
MySQL
- Strong at simple, high-volume reads/writes.
- Perfect for classic web apps: users, posts, orders, etc.
- Very mature, easy to tune for common workloads.
- Vertical scaling is also common here but horizontal scaling is also possible.
MongoDB
- Built with scale-out in mind (sharding).
- Good when you expect a lot of data and many simple operations.
- Often used for event streams, logs, IoT data, and user-generated content.
- Designed for horizontal scaling (add more servers easily). Built for distributed architectures.
- Fast for simple lookups, high write throughput, and large-scale unstructured data.
PostgreSQL vs MySQL vs MongoDB in 2025
How to choose in 2025 (simple decision tree)
Answer these four questions honestly:
- Is your data mostly tabular with relationships (users → orders → items)?
→ PostgreSQL - Do you need rock-solid transactions (money, inventory, bookings)?
→ PostgreSQL (or MySQL if your team already knows it) - Is your data heavily nested JSON that changes every sprint and you hate migrations?
→ PostgreSQL + JSONB (yes, really — it’s faster than MongoDB for most cases now)
→ Only go MongoDB if you truly need schema-less at massive write scale - Are you building logs, real-time analytics, IoT, or a throwaway prototype?
→ MongoDB is still fine
If you answer “I’m not sure” to everything → just use PostgreSQL.
Seriously. In 2025, it’s the default correct answer 90% of the time.
Who Actually Uses What in 2025?
Let’s see a quick example of some real-world use cases.
- PostgreSQL → Instagram, Netflix, Uber, Spotify, Apple (most new services)
- MySQL → Facebook (still), WordPress sites, Shopify, most PHP/Laravel apps
- MongoDB → Mostly legacy or very specific logging/event systems
Tiny Code Reality Check
PostgreSQL (one table + JSONB)
```sql
SELECT u.name, o.total, d->>'street' AS street
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.details ->> 'priority' = 'high';
```MongoDB equivalent (3-stage aggregation)
```
db.users.aggregate([
{ $lookup: { from: "orders", localField: "_id", foreignField: "userId", as: "orders" }},
{ $unwind: "$orders" },
{ $match: { "orders.details.priority": "high" }}
])
```One query vs three stages. That’s why Postgres wins 95% of new apps.
Conclusion for 2025
- PostgreSQL wins. It does relational better than MySQL and documents better than MongoDB for 95% of real applications.
- MySQL is still perfectly fine and powers half the internet but it’s now mostly a legacy comfort choice.
- MongoDB is no longer the cool kid; it’s the specialist tool for specific horizontal-write-heavy, schema-phobic workloads.
There’s no universal single “best” database – there’s the best database for what you’re building. If you’re not sure, or your app is mostly CRUD with structured data? Start with PostgreSQL, MySQL, or H2. Any one of them works.
If your app is very document/JSON-heavy and fast-evolving? Look seriously at MongoDB.
If your stack, team, or tools are already married to MySQL? MySQL will absolutely get the job done.
Note, these are just 3 of the popular databases. We do have more out there. Especially when your data is not structured.
I’ll leave you with this. Just as you’d ask questions to choose the best-fit database for your system, always ask questions before you pull out any outfit.
FAQs: Postgres vs MySQL vs MongoDB in 2025
1. I’m starting a new SaaS / mobile backend in 2025. Which one should I pick?
PostgreSQL (Supabase, Neon, or Render). You get ACID transactions, amazing JSONB for flexible fields, and serverless scaling out of the box. 9 times out of 10, this is the correct answer today.
2. Everyone says MongoDB is dead. Is it really?
No, it’s not dead. it’s just no longer the default. MongoDB is still excellent for logging pipelines, real-time analytics, IoT, event sourcing, and prototypes you might throw away. For normal applications, Postgres + JSONB is simpler and faster.
3. Is horizontal scaling still hard with PostgreSQL?
Stick with MySQL (or migrate gradually). Familiarity beats a slightly better tool. MySQL in 2025 (especially PlanetScale or Aurora) is still rock-solid for classic web apps.
4. Can PostgreSQL really replace MongoDB for JSON-heavy data?
Yes, and it’s usually faster and safer. JSONB is binary, indexed, and supports complex queries. Instagram, Discord, and most new unicorns store semi-structured data in Postgres JSONB columns now.
5. Is horizontal scaling still hard with PostgreSQL?
Not anymore. In 2025 you have:
- Neon (serverless branching + scaling)
- Supabase (full Postgres, auto-scales)
- Citus (open-source sharding)
- AWS Aurora / GCP AlloyDB (fully managed horizontal)
You rarely need to think about it.
6. When should I actually choose MongoDB in 2025?
- You write hundreds of thousands of events per second
- You truly need schema-less documents forever
- You’re building a logging / analytics backend
- You love the MongoDB Aggregation Pipeline and hate SQL
Otherwise → Postgres.
7. What about costs?
- Small–medium apps: all three are basically free on managed tiers
- Large scale: PostgreSQL is usually the cheapest because you avoid MongoDB’s rebalancing headaches and MySQL’s Vitess complexity.
8. What if I pick the wrong one?
You’ll waste months and hundreds of thousands of dollars. The cost of migrating a production database later is brutal. Spend 30 minutes answering the four questions in the decision tree — it’s the cheapest consulting you’ll ever get.
