For many years, when somebody asked me which database to use for a PHP or Laravel application, MySQL was one of the first names that came to my mind.

And honestly, it still makes a lot of sense.

I have worked with MySQL for years. Laravel works very well with it, hosting support is everywhere, developers understand it, and there are millions of applications running successfully on MySQL.

But something interesting has been happening in the developer community.

PostgreSQL is becoming harder to ignore.

According to Stack Overflow's 2025 Developer Survey, PostgreSQL remained the highest-ranked database for developers who want to continue using it or start using it, keeping the top position for the third consecutive year.

This does not mean MySQL is dead.

Far from it.

But I think the real question for developers in 2026 is no longer:

"Which database is popular?"

The better question is:

"Which database is the better fit for the system I am building?"

MySQL is still a very good database

Before comparing anything, I want to make one thing clear.

I don't think developers should suddenly migrate every MySQL application to PostgreSQL.

That would make no sense.

MySQL is mature.

It is widely supported.

It is easy to find developers who know it.

It works very well with Laravel.

It is available on almost every hosting platform.

It performs extremely well for many types of applications.

For a normal CRUD-based SaaS application, MySQL can be more than enough.

The problem starts when developers choose a database only because:

"Everybody uses it."

That is not really a technical reason.

Why is PostgreSQL getting so much attention?

One reason is that modern applications are becoming more complicated.

A typical application is no longer just:

Users
Products
Orders
Invoices

Today we may have:

• JSON data
• Geospatial data
• Full-text search
• Reporting
• Analytics
• Event data
• Complex relationships
• Background processing
• Large datasets
• Distributed systems
• Multiple integrations

PostgreSQL has a reputation for giving developers a very rich relational database with many advanced capabilities built into the database itself.

That makes it attractive for applications where the data model is becoming more sophisticated.

PostgreSQL is still a relational database

Sometimes developers compare PostgreSQL and MySQL as if PostgreSQL is an alternative to relational databases.

It isn't.

Both are relational databases.

Both support:

• Tables
• Relationships
• Indexes
• Transactions
• Joins
• Constraints
• Foreign keys
• SQL

The difference is more about how much functionality and flexibility the database provides and how an application team wants to use it.

One thing I really like about PostgreSQL

For complex applications, I like having more options at the database level.

For example, PostgreSQL has strong support for JSON and structured data.

That can be useful when an application contains some parts that are strongly relational and some parts that are more flexible.

Instead of immediately creating another database just because one part of the data is semi-structured, we can sometimes handle it directly inside PostgreSQL.

Of course, this does not mean:

"Put everything in JSON."

That would create a different problem.

The important thing is having the option when it actually makes sense.

PostgreSQL and JSON

Suppose an ERP system stores product attributes.

Some attributes may be common:

name
sku
price
brand_id
category_id

But different product categories may have different additional properties.

For example:

A laptop:

ram
storage
screen_size
processor

A shirt:

size
fabric
color
fit

A database can model this using normalized tables.

But in some cases, JSON can make specific parts of the model more flexible.

PostgreSQL's JSONB support is one reason it is popular with developers building systems that need both relational and semi-structured data.

Again, I would not use JSON everywhere.

The database design still matters more than the feature.

PostgreSQL becomes interesting for reporting

This is where I think many business applications can benefit.

ERP, CRM and SaaS systems generate a lot of reporting queries.

For example:

"Give me total sales by customer for the last 12 months."

"Show the top products by branch."

"Calculate monthly revenue."

"Find customers who have not purchased in 90 days."

"Compare this year's sales with last year's."

These queries can become complex.

When the application grows, database capabilities become increasingly important.

This is where PostgreSQL often becomes attractive to teams that need more advanced SQL and analytical capabilities.

But MySQL can also handle large applications

This point is very important.

Sometimes articles make database comparisons sound like:

PostgreSQL = advanced

MySQL = basic

That is not true.

MySQL can handle serious production workloads.

There are huge applications running on MySQL.

Performance is not determined only by the database name.

A badly designed PostgreSQL application can be slower than a well-designed MySQL application.

The same is true in reverse.

Database performance depends on:

• Schema design
• Indexes
• Query design
• Data distribution
• Connection management
• Caching
• Hardware
• Read/write patterns
• Transactions
• Partitioning
• Application architecture

I have seen applications blame the database for a problem that was actually caused by a bad query.

Developers often ignore indexes

When a query becomes slow, the first question should not always be:

"Should we change the database?"

Sometimes the answer is simply:

"We need the right index."

For example:

SELECT *
FROM invoices
WHERE company_id = 10
AND status = 'pending'
AND created_at >= '2026-01-01';

If this query runs millions of times, indexing strategy matters.

A well-designed composite index can make an enormous difference.

Changing MySQL to PostgreSQL will not automatically fix a bad indexing strategy.

This is especially important for SaaS

For a SaaS application, I think database architecture becomes more important as the number of tenants increases.

Suppose we have:

Company A → 100,000 records
Company B → 10,000 records
Company C → 500,000 records
Company D → 50 records

Now our application needs to think about:

• Tenant isolation
• Index design
• Data growth
• Large tables
• Archiving
• Reporting
• Backup
• Query performance

The database choice matters.

But the architecture around the database matters even more.

MySQL vs PostgreSQL is not only a performance discussion

This is another mistake I see.

People ask:

"Which one is faster?"

That question is too broad.

Faster for what?

A simple product CRUD system?

A reporting system?

A financial application?

A location-based application?

An analytics platform?

A high-write event system?

A multi-tenant ERP?

A complex SaaS platform?

Different workloads can produce completely different answers.

PostgreSQL's ecosystem is also becoming stronger

Another reason the trend matters is that PostgreSQL is no longer just a database sitting quietly behind an application.

A lot of modern infrastructure is being built around it.

Developers are using PostgreSQL-based platforms for:

• Application databases
• Managed databases
• Serverless applications
• Analytics
• Search-related workloads
• Geospatial applications
• Extensions
• Data-heavy SaaS products

This makes PostgreSQL increasingly attractive for developers who want one strong relational foundation rather than immediately adding many different databases.

The Stack Overflow survey also shows that developers using MongoDB and Redis have a strong desire to add PostgreSQL to their toolkit, which is an interesting signal about where database skills are moving.

What about Laravel?

For Laravel developers, moving from MySQL to PostgreSQL is not as dramatic as many people think.

Laravel supports PostgreSQL as a first-class database option.

The application still has:

Models
Migrations
Controllers
Services
Jobs
Queues
Events
Policies

The framework does not suddenly change its programming model.

But SQL behavior and database-specific features can change.

This is where developers need to be careful.

Database abstraction has limits

Laravel's query builder and Eloquent make database work much easier.

But they do not completely remove database differences.

For example, if we use database-specific SQL, PostgreSQL-specific functionality or MySQL-specific behavior, moving between databases can require changes.

This is why I prefer keeping database-specific logic isolated when possible.

The more our application depends on:

raw SQL
stored procedures
database-specific functions
database-specific indexes

the more carefully we need to plan a migration.

Should a new Laravel project use PostgreSQL?

There is no universal answer.

For a new application, I would ask:

What type of data will we store?

How complex will queries become?

How large do we expect the database to become?

Will we need advanced reporting?

Will we use JSON heavily?

Will we need geospatial features?

What does our hosting environment support?

What does the team already know?

What database will our operational team be comfortable maintaining?

These questions are more useful than simply following a trend.

Should an existing MySQL application migrate?

Usually, no.

Not just because PostgreSQL is trending.

A migration should have a business or technical reason.

For example:

• Current database limitations
• Complex reporting requirements
• Specific PostgreSQL capabilities
• Existing infrastructure standardization
• Large-scale architectural changes
• Long-term operational requirements

If the current MySQL application is stable, fast and easy to maintain, migration can create more risk than value.

Migration means:

• Testing
• Data conversion
• Query changes
• Index review
• Deployment planning
• Downtime planning
• Backup verification
• Production monitoring

That is not a small task.

The interesting trend is not "PostgreSQL wins"

For me, the more interesting trend is this:

Developers are thinking more carefully about database architecture.

A few years ago, many applications used whatever database the hosting provider offered.

Today, developers increasingly choose the database based on the workload.

That is a healthy change.

We should choose technology based on requirements rather than popularity.

What I would do for a new SaaS application

Suppose I start a new SaaS product today.

My first database decision would not be:

"PostgreSQL is trending."

I would start with the data model.

I would define:

Tenants
Users
Roles
Customers
Products
Orders
Invoices
Payments
Audit Logs

Then I would think about:

How much data will we generate?

Which queries will run most frequently?

Which queries will be expensive?

Which tables will grow fastest?

Which data requires strong consistency?

Which data can be cached?

Which reports need aggregation?

After that, I would choose the database.

That is the engineering approach I prefer.

Don't forget Redis

There is another interesting trend here.

The database does not have to do everything.

Redis is becoming more important in modern application architecture. Stack Overflow's 2025 survey specifically noted strong growth in Redis usage.

For Laravel applications, Redis can help with:

• Cache
• Queues
• Sessions
• Rate limiting
• Temporary data
• Locks

So instead of asking:

"MySQL or PostgreSQL?"

the more realistic architecture might be:

PostgreSQL / MySQL
        +
      Redis
        +
      Object Storage
        +
   Search Service

The important thing is knowing why each component exists.

The database should not become our application's bottleneck

One of the biggest lessons from building large business applications is that database performance should be considered from the beginning.

Not when the server starts running out of CPU.

Not when users complain.

Not when a report takes two minutes.

We should monitor:

• Slow queries
• Query count
• Index usage
• Connection count
• Lock contention
• Table size
• Cache hit rate
• Replication lag
• Disk usage

This matters much more than arguing about database popularity.

My final view

I don't think developers need to choose sides.

MySQL is not suddenly obsolete.

PostgreSQL is not automatically better for every project.

But the rise of PostgreSQL is an important trend because it shows that developers increasingly want powerful relational databases with more advanced capabilities.

For someone like me working mainly with Laravel, SaaS, ERP and business applications, I think it is worth learning PostgreSQL even if my current production systems are mostly MySQL.

Because database knowledge is more valuable than database loyalty.

The best developer is not the person who says:

"I always use MySQL."

or:

"PostgreSQL is always better."

The better developer is the one who can look at the application's requirements and say:

"For this system, this database makes sense, and this is why."

That is the kind of database decision I want to make.