- Can I use hyperf/database in a Laravel application?
- Technically it installs with Composer, but it is not a first-party Laravel package and is not the supported path there. Laravel's runtime is request-per-process, while hyperf/database assumes long-lived coroutine workers and connection pooling, so you would end up with two ORM stacks, competing model base classes and duplicated service-provider wiring. For a Laravel app use illuminate/database; adopt hyperf/database only if you are building a Hyperf (Swoole/Swow) service or deliberately porting Laravel to a coroutine runtime.
- What is the difference between hyperf/database and illuminate/database?
- hyperf/database is the database and ORM component of the Hyperf coroutine framework, with an API surface derived from illuminate/database so Eloquent-style code looks familiar. The real difference is runtime: it is PDO-based but built for long-lived workers, coroutine-local context and connection pooling rather than Laravel's request-per-process lifecycle. Treat the similar syntax as familiarity, not drop-in compatibility.
- Does hyperf/database support Eloquent models and the familiar query builder?
- It provides a Laravel-style query builder, models, pagination, transactions, migrations and schema tooling, which is why Eloquent developers recognise the API. Because the surface is derived from illuminate/database rather than identical to it, expect differences in model base classes and service-provider wiring. Validate your specific models, relationships and query-builder usage before committing to any migration.
- How do I install hyperf/database with Composer?
- Install it into a Hyperf application and pin the exact version instead of floating, since v3.2.5 ships without changelog content. Before writing code, confirm Composer resolves cleanly on a fresh install and that the framework's own copy of illuminate/database does not conflict with the pinned derivative. If the resolver will not resolve cleanly, that is your answer on compatibility.
- Is hyperf/database coroutine-safe, and how does connection pooling work?
- Yes — the package is coroutine-safe and PDO-based, with connection pooling designed for Swoole and Swow workers. Pooling is the part that matters most in production: connection lifecycle, per-coroutine context and pool-exhaustion behaviour all differ from a standard Laravel connection. Because the v3.2.5 changelog is empty, review the diff before assuming pool semantics are unchanged from earlier tags.
- Which PHP version and Swoole or Swow extensions does hyperf/database require?
- The PHP floor and any Swoole or Swow extension requirement must be verified against composer.json for the exact tag you intend to use, along with its illuminate/* and PSR dependency ranges. Those ranges are the hard gate: they must not collide with the host framework's own copy of illuminate/database. Confirm it with a clean Composer install rather than assuming.
- Does hyperf/database handle migrations, schema building and transactions?
- Yes — migrations, schema tooling, transactions, pagination and models are all in the package's scope. Transaction and connection semantics are exactly where database layers are riskiest, so a silent change surfaces as data corruption or pool exhaustion rather than a clean error. Read the diff for correctness fixes in query building and transaction handling before upgrading.
- Is hyperf/database actively maintained, and why is the changelog empty?
- The only release artifact available, v3.2.5, contains no changelog entries — just a compare link from v3.2.3 — so release content cannot be assessed from the notes alone. The compare range also skips a v3.2.4 tag, which warrants a maintainer answer on whether it was withdrawn, yanked or simply untagged. Treat any assessment as provisional until the diff is reviewed.
- How do I migrate a Laravel app from Eloquent to hyperf/database?
- There is no incremental path that stops halfway: models, repositories, migrations and DB facades all move together. Run any adoption as a contained pilot behind a repository or adapter interface so the ORM stays swappable, and keep it out of controllers. If the goal was simply to add a database helper to a Laravel app, stop — use illuminate/database or a narrower single-purpose library.
- What alternatives are there for database access in a Swoole or coroutine PHP service?
- For a Laravel application, illuminate/database is the native, supported choice. For Hyperf services, hyperf/database is the framework-aligned option and a high-feasibility fit when pinned rather than floated; for a Laravel app being ported toward a coroutine runtime, the ORM swap must be an explicit, separately funded migration goal. A narrower single-purpose library can be preferable when you only need a query builder rather than a full ORM.