I have spent many years working with MySQL.

For Laravel applications, MySQL is still a very comfortable choice.

I know the syntax.

I know the indexing strategies.

I know how to investigate slow queries.

I know how to use Redis alongside it.

I know how to design tables for large business applications.

So when I look at PostgreSQL, I don't look at it as:

"Another database I need to learn."

I look at it as:

"What can a modern relational database do that I am not using today?"

That question becomes much more interesting with PostgreSQL 18.

PostgreSQL 18 was released on September 25, 2025 and introduced several substantial changes, including a new asynchronous I/O subsystem, skip-scan support for B-tree indexes, uuidv7(), virtual generated columns and OAuth authentication.

For me, this is more interesting than another database popularity comparison.

Because the database itself is becoming a larger part of application architecture.

We usually blame the application first

When a system becomes slow, developers often start here:

Laravel is slow

Then:

PHP is slow

Then:

Redis is slow

Sometimes the real problem is the database.

But even that statement is incomplete.

The real problem may be:

How we designed the query
+
How we indexed the data
+
How the database executes the query

This is why I think modern database features matter.

If the database can execute a workload more efficiently, we don't always need another application layer to solve the problem.

PostgreSQL 18 brings asynchronous I/O

One of the biggest PostgreSQL 18 changes is its new asynchronous I/O subsystem.

The PostgreSQL project says the new AIO subsystem can improve operations such as sequential scans, bitmap heap scans and vacuum operations.

This sounds like a low-level database feature.

And technically it is.

But application developers should care because those low-level operations happen underneath our queries.

Imagine a large table:

Invoices
10 million rows

Now a report scans a significant portion of that table.

The application says:

Run report

The database has to read data from storage.

Storage access can be one of the expensive parts of database execution.

Improving how that work is handled can have an effect on real application workloads.

This is why database optimization is not only about indexes

When developers learn database optimization, we often start with:

Add an index.

That is useful.

But a database engine has many other responsibilities:

Query planning
Index scans
Sequential scans
Memory
Caching
Disk I/O
Concurrency
Vacuum
Transactions

A good database engine is optimizing all of these things continuously.

PostgreSQL 18's AIO work is a reminder that database performance is not only about writing SQL differently.

The engine itself continues to evolve.

Skip scans are another useful improvement

PostgreSQL 18 also added skip-scan support for multicolumn B-tree indexes in more situations.

This is interesting because composite indexes are a very common part of SaaS database design.

Imagine:

CREATE INDEX idx_orders
ON orders (company_id, status, created_at);

Developers often think carefully about the order of those columns.

Why?

Because index design affects which queries can use the index efficiently.

Skip scans give PostgreSQL more options when using multicolumn indexes.

The practical lesson for me is:

Don't assume an index is either "used" or "not used."

The database optimizer is getting smarter about how it can navigate an index.

This makes EXPLAIN even more important

Whenever someone tells me:

"This query is slow."

I don't want to immediately rewrite the query.

I want to inspect the execution plan.

For example:

EXPLAIN ANALYZE
SELECT ...

Then I want to know:

Sequential scan?
Index scan?
Bitmap scan?
Estimated rows?
Actual rows?
Join strategy?
Sort?
Memory?
Execution time?

This is where backend developers can make a big difference.

You don't need to become a database administrator.

But you should be comfortable reading an execution plan.

PostgreSQL 18 also introduces uuidv7()

This is another feature I find particularly practical.

PostgreSQL 18 includes:

uuidv7()

for generating timestamp-ordered UUIDs.

That matters because UUIDs are common in distributed applications.

They are especially useful when we don't want simple sequential numeric IDs exposed publicly.

For example:

Invoice

could have:

5001

or:

019b...

The second style can be useful for public identifiers and distributed systems.

Why are ordered UUIDs interesting?

Random UUIDs can cause less predictable index locality because their values are effectively scattered.

Time-ordered identifiers can improve locality for some workloads.

This becomes particularly interesting for:

High-write tables
Orders
Invoices
Events
Logs
Distributed services

A new record tends to have an identifier that is related to creation time.

That can be useful both for sorting and for certain index behaviors.

UUIDs are not automatically better than integers

This is another place where developers sometimes go too far.

I don't think:

UUID = better

is universally true.

Integers are smaller.

They are simple.

They are easy to index.

They are excellent for many internal database relationships.

I often like the idea of separating:

Internal database ID

from:

Public identifier

Then we can choose based on the application's needs.

PostgreSQL's uuidv7() makes that choice easier

If the application genuinely benefits from UUID identifiers, having timestamp-ordered generation directly in the database is useful.

It also means we don't need to depend entirely on application code or external libraries to generate these IDs.

That is another example of the database becoming more capable.

This matters for SaaS systems

Imagine a SaaS application where customers can create:

Orders
Invoices
Payments
Bookings
Transactions
Events

Millions of records can be generated over time.

We want identifiers that are:

Unique
Distributed-friendly
Harder to guess
Reasonably indexable

There is no single perfect identifier for every table.

But having uuidv7 available as a database primitive gives developers another strong option.

Virtual generated columns are also interesting

PostgreSQL 18 changes generated columns so that virtual generated columns become the default.

Generated columns can represent values derived from other columns.

For example, imagine:

quantity
price

and we want:

total

Instead of calculating the value manually in every application layer, the database can represent a generated value based on the underlying data.

This is useful when the derived field is logically a property of the stored data.

But don't move all business logic into the database

This is where I draw a line.

The database is excellent at:

Data integrity
Constraints
Derived values
Transactions
Queries
Aggregation

But I don't want:

All business rules

hidden inside stored procedures and database-specific logic.

For a Laravel application, I still want the main business logic to be understandable from the application code.

The database should enforce the rules that belong at the data layer.

PostgreSQL 18 also adds OAuth authentication

This one is interesting from a modern enterprise perspective.

PostgreSQL 18 introduces built-in OAuth authentication support.

That means the database is adapting to a world where identity systems are becoming more centralized.

Instead of every database access scenario relying solely on traditional password-based authentication, PostgreSQL can participate more naturally in modern identity architectures.

For organizations with:

SSO
Central identity
Cloud infrastructure
Enterprise identity providers

this can be useful.

Authentication is becoming more centralized

This connects with the passkeys and SSO topic I wrote earlier.

Modern applications are increasingly built around:

Identity Provider
↓
Application
↓
Database

rather than:

Every system
↓
Own username/password database

Database authentication is becoming part of that broader identity architecture.

PostgreSQL's OAuth support is one signal of this shift.

This also shows how databases are becoming more cloud-native

The modern database is no longer just:

Store rows

It increasingly participates in:

Authentication
Security
Performance optimization
Distributed workloads
Application architecture

That is why database knowledge is becoming more valuable, not less.

PostgreSQL 18 is not just about PostgreSQL developers

This is an important point.

Even if I use Laravel, I should care.

Because Laravel eventually produces:

SELECT
INSERT
UPDATE
DELETE
JOIN
WHERE
ORDER BY
GROUP BY

The application framework generates database operations.

The database executes them.

So every backend developer benefits from understanding the database underneath the framework.

ORM abstraction is useful, but it has limits

Eloquent makes database interaction much easier.

I can write:

Invoice::where('status', 'pending')
    ->where('company_id', $companyId)
    ->get();

I don't need to manually write SQL every time.

But eventually:

Table size
+
Complex joins
+
Reporting
+
Indexes
+
Aggregations

force us to understand what SQL the ORM is actually producing.

That is when database knowledge becomes extremely valuable.

The ORM should not hide the database from us

This is something I strongly believe.

A good ORM should make us productive.

It should not make us ignorant.

When I see:

Order::with([
    'customer',
    'items.product',
    'payments',
])->latest()->paginate();

I should still be able to think:

How many queries?
Which joins?
Which indexes?
How much data?
What happens at 1 million orders?

This mindset prevents many production problems.

PostgreSQL 18 makes large queries even more interesting

With improvements to:

I/O
Index scanning
Query execution

we should also remember that database performance depends on workload.

For example:

100 rows

and:

100 million rows

are completely different problems.

A query that is fine today may become expensive next year.

This is why scalability needs to be considered while designing the schema.

Database design becomes more important than framework choice

Sometimes developers debate:

Laravel vs another framework

or:

MySQL vs PostgreSQL

for hours.

But the biggest performance improvement may come from:

Correct schema
+
Correct indexes
+
Correct queries

I have seen badly indexed applications struggle on powerful servers.

And well-designed applications perform surprisingly well on modest infrastructure.

Partitioning is still useful

For very large business tables, partitioning can be another useful database feature.

Imagine:

invoice_logs

contains:

500 million rows

We may not want every query to deal with the complete dataset.

Partitioning by date or tenant-related strategy can help certain workloads.

But again:

Partitioning is not something to add because a table is "large."

It should be based on workload and query behavior.

PostgreSQL 18 also changes how I think about vacuum and storage

The new AIO subsystem specifically improves operations such as vacuum.

This matters because database maintenance is not optional.

A database is constantly doing background work to keep itself healthy.

In a production application, I need to think about:

Vacuum
Statistics
Indexes
Bloat
Storage
Backups
Replication

These are not DBA-only topics once the application becomes large enough.

Backend developers should at least understand the fundamentals.

There is another lesson here: database updates matter

PostgreSQL 18 has already received several minor releases during 2026, including fixes for security issues and bugs. PostgreSQL 18.3 was released on February 26, 2026, and 18.4 on May 14, 2026.

This is important because developers sometimes think:

"We upgraded the database to version 18, so we are done."

No.

Major versions still receive ongoing maintenance updates.

Database patching is part of production maintenance.

Security fixes are another reason to pay attention

PostgreSQL 18.2 included fixes for security issues such as CVE-2026-2003 and CVE-2026-2004, and PostgreSQL 18.4 included additional security fixes including CVE-2026-6479 and CVE-2026-6473.

That is why:

Database
=
Business-critical software

and should be maintained like any other application dependency.

The database is not some permanent black box that we install once and forget about.

PostgreSQL 19 is already coming

The PostgreSQL project currently lists PostgreSQL 19 as the next major release, planned for September 2026.

That shows how quickly this ecosystem continues to move.

Version 18 itself is still relatively new.

But another major release is already on the horizon.

This annual release model gives developers a steady stream of improvements.

This is also why database knowledge compounds

Suppose I learn:

MySQL

and later:

PostgreSQL

The syntax may differ.

Some features may differ.

But the fundamentals remain:

Indexes
Transactions
Isolation
Joins
Query plans
Locks
Normalization
Caching
Partitioning
Replication

These concepts transfer.

So learning PostgreSQL is not throwing away MySQL knowledge.

It makes my database knowledge stronger.

I wouldn't migrate an existing MySQL application just because PostgreSQL 18 is impressive

This is important.

Suppose my Laravel application is:

Stable
Fast
Well monitored
Well indexed

and runs on MySQL.

Why would I migrate?

There needs to be a reason.

Maybe:

Advanced PostgreSQL feature needed
Reporting workload
Data type requirements
Operational standardization
Long-term architecture

Otherwise, migration can introduce:

Risk
Downtime
Testing
SQL changes
Migration complexity
Operational cost

That is not automatically worth it.

For new systems, I would evaluate PostgreSQL more seriously

This is where my opinion has changed.

If I start a new SaaS application today, I would at least evaluate PostgreSQL properly.

Not because:

"PostgreSQL is popular."

But because modern PostgreSQL provides a powerful set of capabilities directly inside the database.

And PostgreSQL 18 shows that this evolution is continuing.

The database can remove application complexity

This is one of my favourite ideas.

Suppose the database can safely handle:

Generated values
Ordering
Constraints
Transactions
Aggregation
Data validation
Indexing

then we don't have to recreate all of that manually in PHP.

The database is very good at data problems.

We should use it.

But we should also keep application-level business logic readable.

The balance matters.

I think backend developers should learn to read the database's point of view

When I write:

Order::where('company_id', $id)
    ->where('status', 'pending')
    ->latest()
    ->paginate();

I should mentally translate it to:

Filter
+
Sort
+
Pagination
+
Index selection
+
Row estimation

Then ask:

What happens when this table has 50 million rows?

That question separates normal CRUD development from production engineering.

The most expensive mistake is often hidden

A query can look perfectly innocent.

SELECT *
FROM orders
WHERE company_id = 10;

Today there may be:

2,000 rows

So it is fast.

Next year:

20 million rows

Now the same query is an architecture problem.

This is why database design needs to consider growth, not just today's data.

PostgreSQL 18 also makes modern IDs easier

I particularly like the combination of:

UUIDv7
+
Distributed applications
+
SaaS
+
Event-driven architecture

This gives us a practical identifier strategy for systems where globally unique IDs are valuable.

Again, not every table needs UUIDs.

But the option is there.

The bigger trend is that databases are becoming smarter

We are moving away from the idea:

Database
=
dumb storage

toward:

Database
=
storage
+
query engine
+
optimizer
+
security
+
concurrency
+
data integrity
+
modern application capabilities

That is a much more accurate picture.

And backend developers should understand that.

My final view

I don't think PostgreSQL 18 is a reason for every Laravel developer to migrate away from MySQL.

I don't think every new application automatically needs PostgreSQL.

But I do think PostgreSQL 18 is a good example of where modern backend development is going.

The database is not sitting still.

It is improving its I/O model.

It is improving index usage.

It is adding better identifier generation.

It is integrating modern authentication.

It is improving generated data capabilities.

And PostgreSQL 19 is already on the roadmap for September 2026.

For me, the biggest lesson is this:

Don't treat the database as a storage box behind Laravel.

It is one of the most important parts of the application architecture.

If I understand the database properly, I can write better Laravel code.

I can design better indexes.

I can diagnose slow queries faster.

I can make better decisions about IDs.

I can understand when caching is necessary.

And most importantly, I can build an application that continues to work when the number of records becomes much larger than it was on day one.

That is the level of database thinking I want to keep developing.