Mysql Laravel Package

Technical Evaluation

Architecture fit: amphp/mysql is an asynchronous MySQL client for the Amp v3 ecosystem (Revolt event loop, fiber-based concurrency), not a Laravel package. It does not integrate with Eloquent, the DB facade, or Laravel's PDO connection resolver, and it cannot serve as a drop-in driver for standard Laravel request lifecycles. Its fit is narrow but real: long-running Amp-based services (async HTTP/WebSocket servers, custom daemons, high-concurrency workers) that need non-blocking MySQL access, or a Laravel application that offloads specific workloads to a dedicated Amp worker process. For a conventional Laravel CRUD app, this package adds architectural surface without benefit.

Integration feasibility: Co-installation with Laravel is straightforward — the package is framework-agnostic and introduces no service providers or config coupling. The cost is operational, not technical: two connection strategies (PDO for the app, Amp for the worker) means two pooling models, two failure-handling paths, and two sets of observability. v3.1.1 is a patch release with no public API changes, so adoption risk from this version specifically is low.

Technical risk: Low for this release. Three signals matter:

• PHP 8.5 readiness — silencing the chr() deprecation in encodeInt8 removes log noise and future-failure risk on PHP 8.5 upgrades. This is a compatibility fix, not a behavior change.
• amphp/[email protected] support — dependency-graph unblocking. Risk is transitive: any other Amp package pinned to [email protected] will now conflict, so composer why-not checks are required before bumping.
• MariaDB native UUID integration test — increases confidence in UUID column handling on MariaDB 10.7+, but it is a test addition, not new codec support. It validates existing behavior rather than guaranteeing it across all protocol paths (binary vs. text).

Key questions:

1. What is the minimum supported PHP version in the 3.x line, and is PHP 8.5 formally in the CI matrix?
2. Does the new MariaDB UUID test cover prepared statements (binary protocol) as well as text protocol, or only one path?
3. Is there a documented upgrade note for consumers currently resolving amphp/[email protected]?
4. What is the maintainer bus factor, and what is the release cadence for the 3.x line?
5. Does the connection pool expose metrics suitable for our observability stack?

Integration Approach

Stack fit: Requires PHP 8.1+ (confirm against the 3.x branch), Amp v3, and Revolt. Sits alongside Laravel 10/11/12 without conflict; does not replace the framework's database layer. Constraint: amphp/[email protected] now permitted, so audit every other Amp dependency for ^3 pins before installing.

Migration path: There is no migration from Eloquent — this is an additive capability. Recommended pattern:

1. Keep Laravel's PDO/Eloquent stack untouched for all synchronous application traffic.
2. Introduce amphp/mysql only inside a purpose-built Amp worker or daemon process.
3. Isolate Amp database access behind a repository/gateway interface so the worker's data layer can be swapped if the async bet doesn't pay off.

Compatibility: Pin ^3.1.1 to pick up the PHP 8.5 and amphp/[email protected] fixes. Verify MariaDB server version is ≥10.7 if native UUID columns are in scope, and confirm that column type is exercised through the code path your worker actually uses. Run composer update --dry-run in a branch first to surface transitive Amp conflicts.

Sequencing:

1. Dependency audit — resolve amphp/file version across the Amp dependency set.
2. Stand up a non-critical Amp worker against a staging MariaDB instance with a UUID column to validate the newly tested path.
3. Run the existing integration suite on PHP 8.5 to confirm the deprecation fix eliminates noise.
4. Pin and roll out to one production worker; measure pool behavior before broadening.

Operational Impact

Maintenance: Patch-level churn is low, but the Amp ecosystem iterates quickly and major bumps in amp, revolt, or file cascade into this package. Budget for periodic dependency maintenance rather than assuming set-and-forget. The [email protected] compatibility in this release is exactly that kind of unblocking change — expect more of them.

Support: Community-maintained with a small maintainer pool; no commercial backing or LTS commitment. Treat it as a dependency requiring internal ownership — someone on the team must be able to read the source and patch it if upstream stalls. Version pinning plus a vendored-fork contingency is prudent for anything on the critical path.

Scaling: The core value proposition — non-blocking I/O with a built-in connection pool — supports substantially higher per-process concurrency than PDO. The operational trap is pool sizing: an Amp worker can open far more concurrent connections than its synchronous equivalent, so pool limits must be reconciled with MySQL max_connections across all workers and replicas. Under-provisioned pools manifest as queuing latency rather than errors, which is easy to miss without pool-level metrics.

Failure modes:

• Pool exhaustion — requests queue silently; needs explicit saturation alerting.
• Connection loss mid-fiber — async failures surface as rejected futures/awaited exceptions, not synchronous throws; unhandled rejections can terminate a worker silently if not caught at the supervisor level.
• Dependency conflict — a [email protected] pin elsewhere blocks upgrade and can leave the fleet on a version missing PHP 8.5 fixes.
• UUID column handling — newly covered by test but historically unvalidated; validate against your actual MariaDB version and protocol path before relying on it.
• PHP 8.5 deprecation noise — resolved by this release in encodeInt8; prior versions will pollute logs and may fail under strict error handlers.

Ramp-up: The principal cost is team familiarity with fiber-based async PHP. Debugging differs materially from synchronous Laravel: stack traces cross fiber boundaries, and the mental model for concurrency and cancellation is new. Plan for a spike or paired implementation before committing to production, and document the worker's failure and restart semantics for on-call.