Weave Code
Laravel Pg Extensions Laravel Package
umbrellio/laravel-pg-extensions
PostgreSQL extensions for Laravel: schema-builder helpers for extensions, views, triggers, functions and rules, plus EXPLAIN query analysis, UNION support, and convenient Eloquent/query-builder additions for Postgres-specific features.
Extensions for Postgres Laravel
Frequently asked questions about Laravel Pg Extensions
- What does the umbrellio/laravel-pg-extensions package actually do?
- It adds Postgres-specific schema-builder helpers to Laravel migrations, covering CREATE EXTENSION, native enum types, CHECK constraints, partial and expression indexes, views, materialized views, triggers, functions, rules, and CREATE TABLE LIKE. It also provides EXPLAIN query analysis, UNION support, and small Eloquent and query-builder conveniences for Postgres features. Architecturally it is a migration-time DSL bolted onto Laravel's Blueprint and grammar layer, not a runtime library that touches your query builder, Eloquent models, connections, or container.
- How do I install umbrellio/laravel-pg-extensions in a Laravel app?
- Run composer require umbrellio/laravel-pg-extensions; the service provider is auto-discovered, so no manual registration is normally needed. After that, use the added Blueprint macros and schema calls in new migrations. Adoption is additive, so you can leave existing migrations untouched and pilot the package on one low-risk table with a single CHECK constraint or partial index. Pin the package version exactly rather than using a loose constraint.
- Which Laravel and Postgres versions does laravel-pg-extensions support?
- The overview does not publish a fixed support matrix, so check the current release's composer.json constraints and the maintainer's CI matrix before adopting. Confirm support for your current Laravel major and the next one you plan to upgrade to, because the package hooks Blueprint macros and grammar internals that have churned across recent Laravel majors. Also validate the Postgres version floor per helper you use, since some features are version-gated, such as NULLS NOT DISTINCT requiring Postgres 15.
- Can I use umbrellio/laravel-pg-extensions with SQLite in-memory tests?
- No. The abstraction is deliberately non-portable and builds on Postgres grammar, so SQLite in-memory tests will hit an incompatibility immediately. You need real Postgres in every environment, including dev, CI, staging, production, and preview branches, or you need a dual-dialect testing strategy. That is an intentional trade: you get fidelity to your production engine at the cost of schema portability you were arguably not honouring anyway.
- How do I create a native Postgres enum column in a Laravel migration with this package?
- You use the package's Blueprint and grammar helpers to create the Postgres enum type and then reference it from the table definition, instead of falling back to raw SQL. Treat converting an existing varchar column to a native enum as a separate project, because it is a full table rewrite under an ACCESS EXCLUSIVE lock. Run it in a lock-timeout-bounded window with a documented reverse path, and never mix that conversion into a normal feature release.
- Does laravel-pg-extensions support partial indexes, CHECK constraints, and expression indexes?
- Yes. The package is specifically built to expose Postgres-native DDL such as CHECK constraints, partial indexes, and expression indexes through Laravel's schema builder rather than scattered DB::statement calls. That replaces untyped raw SQL inside migrations with reviewable, greppable DSL. It is the main maintainability win for teams that already need these Postgres features.
- How does EXPLAIN query analysis work in laravel-pg-extensions?
- The package adds EXPLAIN query analysis so you can inspect Postgres query plans from your Laravel code without hand-writing the SQL wrapper. This is useful for verifying that partial or expression indexes are actually being used by the planner. It is a diagnostic convenience layered on the query builder, not an automatic query optimiser.
- Will php artisan schema:dump or migrate:fresh round-trip my native Postgres schema?
- Probably not fully. Squashed schema files and schema dumps almost certainly will not reproduce native enum types, custom extensions, or partial indexes, which can cause silent drift between a dumped schema and a migrated one in CI or test bootstrap. Test schema:dump and migrate:fresh against your actual schema, and keep raw DB::statement fallbacks where the round-trip loses fidelity. Do not assume the dumped schema is equivalent to running all migrations.
- What are the risks of using native Postgres enums in Laravel migrations?
- Native enum rollbacks are effectively one-way: Postgres cannot drop enum values, and type changes require table rewrites. Adoption therefore needs a documented reverse path and a planned maintenance window if you are converting existing columns. Treat enum work as its own project rather than bundling it into a feature release, and check that your managed Postgres provider permits the extensions you plan to enable.
- Is laravel-pg-extensions actively maintained, and what are the alternatives?
- It is effectively single-vendor, maintained by Umbrellio with around 103 GitHub stars, so the bus factor is low and there is no commercial support path. Each Laravel upgrade becomes a dependency-verification task because the package hooks Blueprint macros and grammar internals. The main alternative is raw DB::statement inside migrations, which is less maintainable but has no upstream risk. Before adopting, decide who owns a fork if upstream stalls, and pin the version.
Weaver
How can I help you explore Laravel packages today?