- Is amphp/sql-common a Laravel package?
- No. It is an internal shared implementation library used by AMPHP SQL drivers, not a Laravel integration package. It has no service provider, facade, configuration, migration support, or Eloquent adapter.
- Do I need to install amphp/sql-common directly in a Laravel app?
- Usually no. It normally arrives transitively when you require amphp/mysql or amphp/postgres. Adopt the driver package and let Composer resolve sql-common; run composer why amphp/sql-common to confirm the dependency path.
- What does amphp/sql-common actually provide?
- It provides common interfaces and utilities shared by the AMPHP MySQL and PostgreSQL drivers, covering connection, statement, result, transaction, and pooling abstractions. These pieces help the driver packages build non-blocking database clients. It is not intended as an application-facing database layer.
- Does amphp/sql-common support Laravel 10 or Laravel 11?
- It has no Laravel-specific version constraints or integration, so Laravel version compatibility is indirect. Compatibility depends on the parent AMPHP driver and runtime, including PHP, AMPHP family versions, and potentially Revolt. Check the parent driver constraints and test the actual stack.
- Can I use amphp/sql-common with Eloquent?
- There is no Eloquent adapter. Laravel's default database stack is synchronous and PDO-based, while Eloquent expects Laravel's connection lifecycle. Using this package with Eloquent would require substantial custom integration and is not its intended role. If async access is required, put the driver behind repository interfaces instead.
- How do I check whether amphp/sql-common is a transitive dependency?
- Run composer why amphp/sql-common. Composer will show which package requires it, likely amphp/mysql or amphp/postgres, along with the version constraint. You can also inspect it with composer show amphp/sql-common to see version and dependents. Treat it as an observed transitive dependency, not a package to adopt.
- What are the production risks of depending on amphp/sql-common?
- It is a low-level shared library with a small public footprint and limited community signal. Its API stability is tied to sibling AMPHP packages, so breaking changes can propagate through parent driver upgrades. Reaching into its internals increases upgrade and support risk. MIT licensing is low risk.
- Does amphp/sql-common handle transactions, pooling, and connection lifecycle?
- It provides shared transaction and pooling abstractions used by the AMPHP drivers. Actual behavior and guarantees come from the parent driver and its version. Verify transaction semantics, connection reset behavior, and error handling against your operational expectations. Do not assume Laravel's connection lifecycle applies.
- How should I test an AMPHP database driver that uses amphp/sql-common?
- Test at the driver level rather than testing sql-common directly. Run a bounded proof of concept under an AMPHP/Revolt event loop if that is your runtime. Wrap the driver behind repository interfaces and test transactions, rollbacks, pool exhaustion, and failure behavior. Benchmark throughput and latency against your current PDO path.
- What alternatives are there to amphp/sql-common for async database access in Laravel?
- For standard Laravel CRUD, reporting, and Eloquent-heavy work, use Laravel's PDO-based database stack; sql-common is a poor fit for those needs. If async I/O is genuinely required, evaluate amphp/mysql or amphp/postgres as the adoption unit, with sql-common arriving underneath as a transitive dependency. Keep the PDO path as a fallback and pin both parent and transitive versions.