Mysql Laravel Package

Product Decisions This Supports

Build vs. buy for async database access. amphp/mysql is the maintained, protocol-level MySQL client for the amphp/Revolt event-loop ecosystem. If the roadmap includes any non-blocking PHP workload (WebSocket/long-lived workers, high-fan-out queue consumers, amphp microservices), this is the "buy" answer versus hand-rolling a wire-protocol client or bolting on a second runtime (Node/Go) for DB-heavy paths. v3.1.1 is a pure maintenance release — no breaking changes — so it is a safe version bump with zero migration cost and can be adopted by teams already on v3.1.x.

PHP 8.5 upgrade planning. The chr() deprecation fix in encodeInt8 is a concrete forward-compatibility signal. This supports committing to a PHP 8.5 upgrade window without carrying a known deprecation in a hot path (encodeInt8 is on every integer bind), and it de-risks "blocked on dependency" appearing in the upgrade plan.

Schema/ID strategy decisions. The new MariaDB CI job plus integration test for native UUID columns is evidence that native UUID/BINARY(16) storage is exercised in CI rather than assumed. This supports choosing native UUID columns over CHAR(36) for new multi-tenant or externally-exposed ID schemes, with third-party validation rather than our own spike as the basis.

Dependency-graph hygiene. amphp/[email protected] compatibility lets us hold a single consistent amphp v3 stack instead of pinning mixed major versions — reduces Composer conflict churn and the maintenance tax of exception-pinning transitive deps.

Confidence in the support matrix. A patch release whose headline work is CI expansion (MariaDB) and deprecation silence is a healthy maintenance signal: the maintainers are investing in test coverage and forward compatibility, not just features. Low churn + active CI is the profile we want in a foundational dependency.

When to Consider This Package

Adopt when:

• You are building amphp/Revolt-based services (or an async worker tier) that need genuinely concurrent MySQL I/O per process, and blocking PDO is the measured bottleneck.
• You need connection pooling and non-blocking queries inside long-lived processes, and per-worker blocking connections have become the scaling constraint.
• You are standardizing a PHP 8.4/8.5 service fleet and want a dependency with demonstrable forward-compat maintenance.
• You are using native UUID columns and want a client whose CI actually covers that against MariaDB.

Look elsewhere when:

• The application is a conventional Laravel app on PHP-FPM. PDO + Eloquent/Query Builder is simpler, faster to onboard, and there is no first-party Laravel DB connector or service provider here — you own the glue code.
• You need an ORM: this is a driver, not an abstraction over models. There is no Eloquent integration, no migrations, no model events, no lazy-loading semantics.
• Your team is not fluent in async/futures (Revolt\Future, await). Async data access changes transaction and error-handling patterns, and debugging async stack traces has a real learning curve and on-call cost.
• Horizontal scaling is cheaper than re-architecting: if you can add PHP-FPM workers for less than the engineering cost of owning an async data layer, do that.
• You need Postgres — evaluate amphp/postgres separately; do not assume parity.

Adoption criteria to gate on: a written owner for the Laravel/amphp glue layer, an async-capable reviewer on the team, and a benchmark showing the blocking PDO path is actually the constraint.

How to Pitch It (Stakeholders)

For executives: A mature, low-churn, actively maintained async MySQL client for PHP. The v3.1.1 release contains no breaking changes — it is a forward-compatibility and test-coverage release (PHP 8.5 readiness, MariaDB CI, native UUID coverage, amphp/[email protected] alignment). Cost is engineering glue and ramp-up, not licensing. Recommendation: targeted adoption for async/long-lived workloads, not an org-wide replacement for the existing Eloquent/PDO stack.

For engineering: Safe to bump to v3.1.1 — no API changes, no deprecations introduced. It unblocks PHP 8.5 upgrades and lets us collapse to a single amphp v3 dependency set. Native UUID column support is now CI-verified against MariaDB, so we can commit to BINARY(16) IDs with confidence. Be explicit that this is a driver: adopting it means owning the Laravel integration and moving those code paths off Eloquent. Scope it to a service or worker tier, benchmark against the current PDO path, and decide on evidence.