- Is laminas/laminas-db compatible with Laravel?
- It is Composer-installable into any Laravel application, but nothing in the package is Laravel-aware: there is no service provider, no config binding, no facade, and no Laravel-focused documentation. You must construct the Adapter yourself and register it in Laravel's container by hand. Treat it as a bounded component behind an application-owned interface rather than a framework integration.
- How do I install laminas/laminas-db in a Laravel application?
- Run composer require laminas/laminas-db, then build an adapter manually, for example new \Laminas\Db\Adapter\Adapter([...]) with your driver and connection parameters. Bind that instance as a singleton in a service provider so it can be injected where needed. Be aware that optional features pull in laminas-servicemanager, laminas-eventmanager, laminas-stdlib, and laminas-hydrator, which is a meaningful dependency chain for a capability Laravel already provides.
- Does laminas/laminas-db replace Eloquent or the Laravel query builder?
- No, and using it as a general replacement is a poor fit. It duplicates three concerns Laravel already owns: connection and driver management, SQL construction, and row/result-set hydration plus persistence patterns. Running two database abstractions side by side typically produces inconsistent data-access code across a team.
- When should a Laravel developer choose laminas/laminas-db over Eloquent?
- Only in narrow cases: porting Zend Framework-era code, working with Oracle, IBM DB2, or SQL Server through its vendor-specific adapters and platform classes, or satisfying an acquirer-imposed RowDataGateway and TableDataGateway standard. If you only need those gateway semantics, consider re-expressing them as repositories over Eloquent instead. Alternatives like Doctrine DBAL or Laravel's own DB facade are usually better default choices.
- How do I use TableGateway or RowGateway inside Laravel?
- Instantiate TableGateway with your configured adapter and table name, optionally enabling features such as metadata or RowGateway. Wrap those calls inside a repository or service class resolved from Laravel's container. Avoid injecting TableGateway into controllers, jobs, or Blade views, and keep the adapter behind an interface so the exit path stays cheap.
- Is laminas/laminas-db still actively maintained?
- It is in security-only maintenance mode following a Laminas Technical Steering Committee decision, and the README explicitly invites a new maintainer. That means no new features, no new database-vendor support, and no compatibility work for future PHP or Laravel majors, only security patches. For a Laravel shop, a security-only dependency sitting under the data layer is a long-term liability, so plan an exit strategy before adopting it.
- Which databases does laminas/laminas-db support?
- It supports PDO connections such as MySQL, PostgreSQL, and SQLite, plus driver-based adapters for SQL Server, Oracle, and IBM DB2 through platform classes that handle identifier quoting and platform-specific SQL differences. That platform breadth is its strongest argument in a Laravel context. Verify the required PHP extensions are present in your runtime before committing.
- Does laminas/laminas-db work with Laravel 10, 11, or 12?
- Because the package is framework-agnostic, its constraints come from your PHP version and its Laminas dependencies rather than the Laravel version itself. Since it is security-only, pin the version in composer.json and test Laravel and PHP upgrades in CI before rolling them out. Watch for subtle behavioral changes in patch and minor releases, such as HydratingResultSet::current() returning null instead of false.
- Can I use laminas/laminas-db and Eloquent in the same application?
- Yes, but isolate them deliberately. Bind the Adapter as a named singleton, keep all Laminas queries in a dedicated namespace or module, and never mix the two abstractions in a single class. Document the boundary and decide up front whether the arrangement is transitional or permanent, because running two database abstractions indefinitely raises the cost of every future change.
- How do I test code that uses laminas/laminas-db in Laravel?
- Inject the Adapter rather than constructing it inside classes so you can substitute a test double or a real test database. For SQL construction, build Sql objects and assert on the generated strings, and run integration tests against each vendor you actually target, especially Oracle or DB2. Wrap TableGateway calls in repositories so most of your test suite can mock the repository instead of the database layer.