- How do I install tpetry/laravel-postgresql-enhanced in a Laravel app?
- Install it with composer require tpetry/laravel-postgresql-enhanced; there is no service provider or config file to publish for basic use. Optionally register the bundled PHPStan extension (auto-detected via phpstan/extension-installer, or added manually as an include line) and generate Laravel Idea helper files so IDEs autocomplete the extra schema and builder methods. The package plugs into Laravel's existing extension points rather than patching core, so it coexists with a standard application.
- What PostgreSQL features does this package add to Laravel?
- It restores Postgres-native capability that Laravel's lowest-common-denominator schema builder leaves out: extensions, functions, triggers, views and materialized views, richer foreign keys, and advanced indexes including concurrent, partial, functional, INCLUDE-column, fulltext and temporal indexes. It also adds domain types, table options such as unlogged tables and storage parameters, zero-downtime migrations, CTEs, lateral joins, RETURNING support and lazyByCursor. The goal is to let you express these as structured, reviewable migrations instead of raw DB::statement calls.
- Which Laravel and PHP versions does laravel-postgresql-enhanced support?
- The package follows semantic versioning, so minor and patch upgrades are intended to be safe, but its major version is effectively pinned to your Laravel major. Laravel periodically ships database features this package already provided with different semantics, which forces a package major bump, so upgrading Laravel often means upgrading this package in the same change. Treat the two artifacts as a coordinated pair and check the README breaking-changes section before each framework upgrade. Confirm the exact tested matrix of Laravel majors, PHP versions and PostgreSQL releases on the repository before committing.
- Is laravel-postgresql-enhanced a fork of Laravel's database layer?
- No, it is a decorator: it ships a PostgreSQL-specific connection and grammar layer plus its own Schema facade and Blueprint that are supersets of Laravel's, wired in through macros, builder mixins and schema grammar extension points. That means it coexists with a normal Laravel app and can be adopted connection by connection. The one convention to enforce is imports: both Tpetry's Blueprint and Illuminate's Blueprint exist, so enhanced migrations must import the package's class, which is best handled with lint rules and code review.
- How do zero-downtime migrations work and what happens if one times out?
- The wrapper runs the migration under a timeout and, on cancellation, resets the schema state so a failed deploy does not leave a half-applied change. That is valuable for production, but it is also an incident vector when the DDL is non-transactional, for example CREATE INDEX CONCURRENTLY, because an incomplete reset can leave objects behind. Test the timeout path against your actual migration set in staging and verify the resulting database state rather than assuming the rollback is total.
- Does it work on managed PostgreSQL like RDS, Cloud SQL or Azure Database?
- Many features work anywhere, but creating extensions and functions requires elevated privileges that managed services often restrict or require you to enable explicitly. Optional types such as pgvector, ltree, hstore and Timescale are only usable where the extension is actually installed, so verify availability per target environment. Check with your platform team which extensions are permitted before designing migrations around them.
- Can I use this package in an app that also supports MySQL or SQLite?
- The package presumes PostgreSQL everywhere, so scope it rather than making it a global assumption; portable code paths should keep using Laravel's own Blueprint and grammar. Adopt it per connection, applying the enhanced schema facade only to Postgres-backed services, and keep SQLite-in-tests setups on the standard classes. If a portability requirement appears later, the enhanced layer becomes a Postgres-only tool rather than something the whole codebase depends on.
- How do I get IDE autocomplete and PHPStan support for the extra schema methods?
- For PHPStan, include the package's extension (automatically via phpstan/extension-installer or with an explicit include line in phpstan.neon) so static analysis understands the enhanced SQL generation and builder methods. For autocomplete, generate the helper files with Laravel Idea, which teaches the IDE about the package's Blueprint and schema macros. Wiring both is the low-friction part of adoption and is worth doing on day one.
- How do I create a concurrent or partial index in a Laravel migration with this package?
- Use the package's Blueprint methods inside your migration instead of raw SQL: mark an index as concurrent to emit CREATE INDEX CONCURRENTLY, add a where clause for a partial index, and pass INCLUDE columns or storage parameters where needed. Functional indexes and column options let you index expressions rather than plain columns. Because concurrent builds are non-transactional, run them outside a wrapping transaction and confirm the zero-downtime wrapper's behaviour in staging.
- Is laravel-postgresql-enhanced actively maintained and safe to depend on?
- It is a well-regarded package with roughly a thousand GitHub stars, but it is maintained by a single author and has limited tracked dependents, which is a weak adoption signal for a critical dependency. The mitigation is a proof of concept on your real schema first, plus a named owner and cadence for testing package compatibility whenever Laravel is upgraded. Keep minor and patch upgrades routine, and treat major upgrades as a planned, reviewed change.