Weave Code
Laravel Optimized Postgres Laravel Package
genealabs/laravel-optimized-postgres
GeneaLabs Laravel Optimized Postgres brings PostgreSQL-specific performance enhancements to Laravel's query builder and Eloquent, helping you write faster queries and better use native Postgres features. A lightweight drop-in for apps already running Postgres.
optimizes field types for Postgres.
Frequently asked questions about Laravel Optimized Postgres
- How do I install genealabs/laravel-optimized-postgres in a Laravel app?
- Install it with Composer using composer require genealabs/laravel-optimized-postgres, then optionally publish the package config. It is described as a drop-in for applications already running PostgreSQL, so it applies to existing models and migrations rather than requiring a rewrite. One caveat: the Composer vendor is genealabs while the GitHub repository sits under mikebronner, so confirm you are pulling the intended package.
- Which Laravel and PHP versions does version 13.0.0 support?
- Release 13.0.0 is a compatibility major aligned with Laravel 13 and PHP 8.5, and it ships with no announced feature or API changes. Packages that track Laravel majors usually drop older php and illuminate/* constraints at that boundary, so 13.0.0 is likely unusable unless you are on, or funded to reach, Laravel 13 plus PHP 8.5. Read the real composer.json for exact constraints and confirm whether the 12.x line still receives fixes before planning an upgrade.
- What PostgreSQL features does this package add to Laravel's query builder and Eloquent?
- The advertised capabilities are JSONB, native arrays, hstore, CITEXT, UUIDs, range types, tsvector and GIN full-text search, and ON CONFLICT upserts. The catch is that the 13.0.0 release notes describe none of these, so every claim currently lives in README and marketing copy. Validate each capability against the source code before it anchors a roadmap commitment.
- Does genealabs/laravel-optimized-postgres work with MySQL or other databases?
- No. The package is explicitly scoped to PostgreSQL-primary applications, and on a MySQL-first or genuinely multi-engine stack its value proposition collapses to zero. In that situation the dependency is pure overhead. Only adopt it where PostgreSQL is the production database.
- Is this package safe to run in production?
- Treat it as a named risk-register entry rather than ambient unease: it has a single maintainer, 58 GitHub stars, zero dependents, no support contract, no published deprecation policy, and no benchmark data. Zero dependents also means there is no independent production validation to borrow confidence from. The leading-edge pairing of Laravel 13 and PHP 8.5 compounds upstream-bug exposure with bus-factor exposure.
- Will it conflict with other packages that extend Laravel's query builder or schema builder?
- That is an open question in the technical evaluation and must be tested rather than assumed. The package augments the stock pgsql driver, so anything else touching connectors, the schema builder, or the query builder is a potential collision. Install it in a branch with your full dependency set and exercise your JSONB, array, and upsert paths before adopting.
- Does it replace Laravel's PostgreSQL driver or just augment it?
- The evaluation frames it as a service-provider augmentation of the stock pgsql connection, which would be config-level and reversible, but it explicitly says that must be verified rather than assumed. The distinction decides whether removing the package is a config change or a structural exit. Read the service provider and connector code before committing.
- Are there benchmarks showing faster queries or lower cloud costs?
- No benchmark data is published, and any performance or cloud-cost narrative attached to this package is unsupported and should be blocked at the door. The realistic value is maintenance elimination, not raw speed: stopping teams from re-writing the same Postgres SQL in every service. If you need numbers, measure against your own workload.
- How actively maintained is genealabs/laravel-optimized-postgres?
- There is one contributor, 58 stars, zero dependents, and no published deprecation policy or support contract. A major bump with a two-line changelog and no upgrade guide is the classic shape of a package that compiles everywhere in development but breaks the one service still on the previous major. Check the CI matrix, issue-response latency, and tag cadence yourself before committing.
- What are the alternatives if I only need one or two Postgres features?
- Most teams currently hand-roll that SQL in repositories and query macros, which is exactly the repeated tax this package aims to remove. If you only need a single capability such as JSONB querying or bulk upserts, keeping the raw SQL local is cheaper than adding a single-maintainer dependency. If you do adopt it, define the exit path up front, whether that is pinning, forking, vendoring, or reverting, along with the trigger that starts it.
Weaver
How can I help you explore Laravel packages today?