Laminas Db Laravel Package

Product Decisions This Supports

• Legacy portfolio triage. This package is the clearest fingerprint of a Zend Framework / Laminas application in your estate. If it appears in a dependency audit, you are looking at a legacy PHP service, not a modern Laravel one — that determines whether the next decision is "maintain," "strangle," or "sunset."
• Build vs. buy for the data-access layer. Laminas\Db already provides SQL abstraction, result-set abstraction, and RowDataGateway/TableDataGateway implementations across MySQL, PostgreSQL, Oracle, DB2, SQL Server, and PDO. For a legacy service, that is a real replacement cost if your team proposes hand-rolling a query builder or repository layer — quantify it before approving the work.
• Migration roadmap and effort sizing. The package gives you a concrete mapping table for a Laravel migration: Sql\Select → Query Builder, TableDataGateway → Eloquent model or repository, HydratingResultSet → API Resource / DTO hydration, Adapter → Laravel's DB connection. Every usage site is a work item; the count of TableGateway and Sql imports is a defensible proxy for migration scope.
• Vendor and license due diligence. BSD-3-Clause is permissive and carries essentially no legal friction. The risk here is not licensing — it is maintenance posture (see below).
• Standardization guardrail. The decision this package most directly supports is a "no" — do not introduce it into new Laravel services. Adopting it alongside Eloquent means two query layers, two connection-configuration paths, two testing strategies, and two hydration models in one codebase.
• Maintenance-contract scoping. Because the project is feature-complete and in security-only mode, any roadmap item that depends on new capability from this library is effectively blocked. That constrains what you can promise customers on top of it.

When to Consider This Package

Consider it when:

• You are maintaining an existing Laminas/Zend MVC application that already depends on it. Ripping it out is a migration project, not a cleanup task, and "leave it alone, patch security" is a legitimate product decision.
• You need RowDataGateway / TableDataGateway patterns in a non-Laravel PHP codebase and the team is already fluent in the Laminas idiom.
• You have a genuine multi-vendor legacy database estate — Oracle, IBM DB2, SQL Server, PostgreSQL, MySQL behind one API — and rewriting the abstraction is out of scope for the current planning cycle.
• You are running an incremental strangler migration and need the old data layer to keep working, untouched, while new endpoints are built in Laravel alongside it.
• You need a containment boundary: wrapping existing usage behind repository interfaces now so the eventual replacement is a swap, not a rewrite.

Look elsewhere when:

• The work is greenfield Laravel. Use Eloquent and the Query Builder. There is no scenario where adding this package to a new Laravel service is the right call.
• You need active feature development, modern driver support, or forward PHP compatibility guarantees. Security-only maintenance means bug fixes and CVE patches, not roadmap responsiveness. The README explicitly invites a new maintainer, which is a signal about succession risk, not a feature backlog.
• You need a modern, actively maintained DBAL for non-Laravel PHP. Doctrine DBAL is the conventional answer and has a materially healthier ecosystem.
• Ecosystem depth matters to your risk model. At ~145 stars and effectively no downstream dependents, community support, third-party integrations, and Stack Overflow coverage are all thin. Your team will be reading source, not tutorials.
• Security-only posture is unacceptable for the service in question — for example, a customer-facing system with a long support horizon and no planned replacement.

How to Pitch It (Stakeholders)

To executives: This is a frozen, permissively licensed component inside our legacy PHP stack. The license is a non-issue; the maintenance model is the issue. It is feature-complete and receives security fixes only, so treat it as a stable asset to be contained, not expanded. The ask is not budget to adopt it — it is budget to exit it on a planned timeline, plus a small ongoing allowance for security patching in the interim. The headline risk is key-person and succession risk on an upstream project that is openly asking for a new maintainer, not an immediate outage risk.

To engineering: Do not standardize on this in new Laravel services — one query layer, one hydration model, one connection config. Where it already exists, do not refactor it opportunistically; instead put a repository interface in front of every TableGateway and Sql usage so the blast radius is bounded and the replacement is a swap. Route all database access through the adapter, never through platform-specific PDO handles (upstream itself flags that pattern as unsafe). Treat the dependency as security-patch-only: track advisories, pin versions, and do not plan features that require upstream changes. When you migrate a module to Laravel, migrate the data access with it — a half-migrated service running Eloquent and Laminas\Db against the same schema is the outcome we are explicitly trying to avoid.