laravel-postgresql-enhanced gives Laravel the PostgreSQL features it leaves out

Laravel's portability is the problem the package solves

The README states the motivation in a single paragraph, and it is a good one. Laravel supports many different databases and therefore has to limit itself to the lowest common denominator of all databases. PostgreSQL, however, offers a ton more functionality which is being added to Laravel by this extension.

That framing explains the shape of the package. Everything in it is something a portable query builder cannot offer, because offering it would break the other databases Laravel supports. The package is not a better query builder, it is the set of things you give up when you insist on one query builder for many databases.

The audience follows directly. A team that has chosen PostgreSQL deliberately, and has decided that the cost of losing PostgreSQL features is higher than the cost of losing portability, gets a large surface of new capability. A team that might switch to MySQL later gets a dependency they cannot use.

The repository is a PHP package with a Laravel service provider style layout, with src/ holding the implementation and tests/ the suite, and the tooling is visible in the file names: phpunit.xml.dist for the tests, a.php-cs-fixer.dist.php for style, phpstan.neon.dist and phpstan-extension.neon with its PHP file for static analysis, ide.json for IDE metadata, and testbench.yaml, which is the Laravel package testing harness. The licence is MIT, the last push was on 2026-10-14, and the repository publishes no GitHub releases, so the version history is in the CHANGELOG.md and in Packagist.

Minor and patch are safe, and a Laravel upgrade can break you

The versioning policy is the section of the README that a team should read before installing anything, because it describes a coupling that is unusual for a Composer package.

The package follows the semantic versioning policy, so you can always safely upgrade to a new minor and patch version without any issues. The catch follows immediately. Laravel is a healthy framework that is still adding new database functionality, so some things may break. The example given is that Laravel introduced new builder methods that had already been part of this package for a long time, but with different semantics, and in such cases a new major version of this package is promptly released with the breaking change to align with Laravel's implementation.

The practical consequence is stated in one line. When upgrading Laravel, you may also have to upgrade this package to a new major version when something breaks.

So the dependency is not independent of the framework version. A Laravel upgrade is a two step job, and the order matters, because the package's major version has to be chosen to match the Laravel release it was built against. The README points at the breaking changes section for the minimal list of changes over the past years, which is the reference to read before scheduling that upgrade.

This is a real cost, and it is the price of the feature set. A team that upgrades Laravel annually will feel it, and a team that wants a boring upgrade path should look at how many of these features they actually use before taking the dependency.

Migrations that abandon themselves when they run too long

The zero downtime migration feature is the most interesting thing in the package, and it is a safety mechanism rather than a performance feature.

For applications with 24/7 requirements, migrations must never impact availability. PostgreSQL provides many functionalities to execute changes on the schema without downtime. However, sometimes a change to the schema is not tested sufficiently and locks the tables for a longer period of time in order to make the desired change. To avoid that problem, a migration can be marked as a zero downtime migration, and if the migration exceeds a specified time limit, it is cancelled and the schema is reset to its original state.

The mechanism is a trait on the migration class, and the up and down methods use the enhanced Blueprint.

use Tpetry\PostgresqlEnhanced\Schema\Concerns\ZeroDowntimeMigration;
use Tpetry\PostgresqlEnhanced\Support\Facades\Schema;

class Test123 extends Migration
{
    use ZeroDowntimeMigration;

    public function up(): void
    {
        Schema::table('user', function (Blueprint $table) {
            $table->string('name', 128)->change();
        });
    }
}

The timeout is configurable per migration, with a timeout of a maximum time limit of 1.0 second settable separately for each migration. You can set private float $timeout = 5.0 on the migration for an up and down timeout, or set the specific timeouts $timeoutUp and $timeoutDown to differentiate between the methods.

The trade is deliberate and worth understanding. A migration that would have succeeded given more time now fails and rolls back, which is the right outcome for a table with traffic on it and the wrong outcome for a table with none. The timeout is a per migration decision, so a team can apply it where it matters.

The feature surface is wide, and the list is the documentation

The README's table of contents is long, and it doubles as the specification of what the package covers. Reading it as a list of PostgreSQL features rather than as Laravel API surface makes the scope clear.

On the index side there are indexes concurrently, nulls not distinct, partial indexes, include columns, if not exists, storage parameters, functional indexes and column options, fulltext indexes and temporal indexes. On the table side there are unlogged tables, storage parameters and row level security. On the column side there are compression, initial and using, and a long list of types including arrays, ranges, bit strings, case insensitive text, full text search, hstore, identity, IP networks, international product numbers, label tree, vector and XML. There are also domain types and grants.

The query features are the other half, and they are the ones a developer notices first. Explain, fulltext search, lateral subquery joins, returning data from modified rows, common table expressions, lazy by cursor, where clauses and order by.

And there are the Eloquent level additions, casts, refresh data on save and date formats, plus a lazy transaction at the connection level, expressions, and a list of supported extensions where Timescale is named.

Two things are worth noticing about the shape of that list. The query features, and the casts, are the ones that change how application code is written rather than how the schema is built, and they are the reason the package also ships static analysis support. And the presence of Timescale and vector in the same list tells you this is aimed at modern analytical and AI workloads, not at a legacy application that happens to use PostgreSQL.

Static analysis and autocomplete come with the package

Adding methods to a framework is one problem, and telling the tooling about them is another, and the package solves the second one too.

The PHPStan side is the more systematic solution. A custom set of PHPStan extensions have been developed to get full static analysis support, and all features provided by the extension are automatically recognised by the phpstan/extension-installer. Otherwise you have to add the path to the includes list in phpstan.neon yourself, and the README shows what that file should look like.

includes:
    - ./vendor/nunomaduro/larastan/extension.neon
    - ./vendor/tpetry/laravel-postgresql-enhanced/phpstan-extension.neon

The IDE side is narrower, and the README is honest about why. Laravel provides many extension capabilities, making it hard for IDEs to do proper autocomplete, and there is currently no generic way to tell IDEs about the added functionality of this enhanced driver. What exists is an integration with specific IDE combinations. With PhpStorm and Laravel Idea, the IDE Helper for Laravel can detect all PostgreSQL features by running the Generate Helper Code action from the Laravel to Code Generation toolbar menu.

So the autocomplete story depends on a helper package and a manual action, while the static analysis story is automatic. That asymmetry is a fair description of where the tooling is today, and the ide.json file in the repository root is the metadata that makes part of it work.

Editorial conclusion

laravel-postgresql-enhanced fits a Laravel team on PostgreSQL that has outgrown the portable subset, for example because it needs vector columns, full text search, domain types or zero downtime migrations on a busy table. It is the wrong choice for an application that may move to another database, because every method it adds is PostgreSQL specific by definition. Verify first which major version of the package matches your Laravel version, since the README states that a Laravel upgrade can force a major upgrade here, and check that the index and table options you want are in the feature list rather than assuming the whole PostgreSQL surface is covered.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. tpetry/laravel-postgresql-enhanced on GitHub