PostgreSQL 14 Is End of Life and PostgreSQL 19 Arrives November 19: What a Laravel App Should Do

PostgreSQL 14 received its final release on November 12, 2026 (14.25) and is now end of life: no more security or bug fixes. The same day the project released a security update for every supported version that closes 52 vulnerabilities, and the second release candidate of PostgreSQL 19, whose general availability is planned for November 19, 2026. If your Laravel app still talks to a 14, that update is the last one it will ever get, and it is the one that matters most. If you are on 15 to 18, you are fine on support; the question is just which jump to make and when.

Everything below comes from postgresql.org (the November 12 announcement, the versioning policy and the PostgreSQL 19 release notes, whose date line reads “as of 2026-10-09”), checked on November 13, 2026. PostgreSQL 19 is not released yet, so treat what I say about it as a preview.

Support dates

PostgreSQL supports each major version for five years. From the versioning policy page:

Laravel is not the constraint here: the Laravel 13 database docs list PostgreSQL 10.0+ as supported, so the framework will talk to anything from 14 to 19. The limit is the database’s own support window.

The update you should apply first

The November 12 release fixes 52 security vulnerabilities and more than 140 bugs. Several need steps after updating, according to the announcement’s “Updating” section:

• Reindex pg_trgm GiST indexes (possible missed matches), and B-tree indexes on bpchar columns declared without a length.
• Take a new full backup after updating if you use incremental backups.
• Check NOT NULL NO INHERIT constraints on partitioned tables.

If you are on 15 to 18, install the matching minor (15.20, 16.16, 17.12 or 18.7) and read that section. If you are on 14, you can apply 14.25 as a stopgap, but the next vulnerability has no fix coming: plan the major upgrade, don’t just patch.

Which version to move to

My recommendation for a production Laravel app today is PostgreSQL 18 (18.7, supported until November 14, 2030), or 17 if your host does not offer 18 yet. PostgreSQL 19 is a new major release, and a new major tends to collect its first fixes in the minor releases that follow. Going from 14 to 19 the week it ships gains you little over 18, which already has a support window until 2030. That is an opinion, not a rule: if you are starting a new project, 19 is a reasonable choice once 19.1 is out.

Any major jump needs pg_upgrade, a dump and restore, or logical replication; there is no in-place minor-style upgrade.

What PostgreSQL 19 changes (from its release notes)

The notes list incompatibilities with earlier releases. The ones I would check in a Laravel app:

• standard_conforming_strings is now always on. Dumps from older pg_dump made with it off will not load into 19; make the dump with the 19 client tools.
• json_array() with no rows returns an empty array instead of NULL. Look at raw queries and accessors that treat NULL as “no items”.
• JIT is disabled by default. Relevant if you run large analytical queries and relied on it.
• max_locks_per_transaction default goes from 64 to 128, and the io_workers variable is replaced by four new ones (that matters for your postgresql.conf, not for Laravel).
• MD5 password authentication now logs a warning after a successful login (MD5 was deprecated in 18). If your role passwords are MD5, move to SCRAM before the warning becomes noise.
• RADIUS authentication is removed.
• pg_upgrade refuses clusters with btree_gist indexes on inet/cidr columns, and newlines or carriage returns in database or role names.

New features worth knowing: a REPACK command (with a CONCURRENTLY option that doesn’t block reads or writes), faster foreign-key checks, logical replication of sequences, and a WAIT command for read-your-writes consistency on standbys. Nothing of that changes how Eloquent or the migrations work; the benefit is operational.

Checks for a Laravel app

# What version is the app actually talking to?
php artisan db:show

# Or from tinker / SQL
php artisan tinker --execute="dump(DB::select('select version()'));"

• Before upgrading, run your test suite against the target version in CI (a postgres:18 service container is enough). Tests on SQLite do not catch Postgres differences, so this is the one that matters.
• Search for raw SQL that uses json_array, COPY or version-specific settings.
• Behind PgBouncer or a pooler? Laravel 13 has a documented direct connection option for pooled PostgreSQL connections that makes migrations and maintenance commands use a direct connection; check it still applies after the upgrade.
• Rehearse the upgrade on a copy of production data and time it: the downtime of pg_upgrade or a restore scales with data size.

Frequently asked questions

When did PostgreSQL 14 reach end of life?

PostgreSQL 14 received its final release (14.25) on November 12, 2026, according to the versioning policy and the release announcement of that day. It no longer receives security or bug fixes.

When is PostgreSQL 19 released?

The PostgreSQL project says the planned date for general availability of PostgreSQL 19 is November 19, 2026. The second release candidate came out on November 12, 2026, and release candidates are mostly identical to the final release.

Which PostgreSQL versions does Laravel 13 support?

The Laravel 13 database documentation lists PostgreSQL 10.0 or newer. The real limit is the database support window: PostgreSQL 15 is supported until November 11, 2027, 16 until November 9, 2028, 17 until November 8, 2029 and 18 until November 14, 2030.

Do I need to dump and restore to upgrade PostgreSQL?

For a major version change you need a dump and restore with pg_dumpall, pg_upgrade or logical replication, according to the PostgreSQL 19 release notes. Minor updates within the same major version (for example 18.6 to 18.7) are a binary replacement and restart.

Is it safe to move to PostgreSQL 19 right away?

It is a judgment call. PostgreSQL 19 is planned for November 19, 2026 and has not shipped as of this writing. For production I would choose 18 (supported until November 14, 2030) and consider 19 once the first minor releases are out; for a new project 19 is a reasonable choice.