Amphp Sqlite3 Laravel Package

Technical Evaluation

Architecture fit

• Amp is an event-loop/coroutine runtime. Laravel is a synchronous, request-per-process framework. The two coexist cleanly only when everything in the call path is async; running Amp's loop as a blocking island inside an HTTP request adds failure surface while delivering none of the non-blocking benefit (PHP-FPM would have blocked on PDO anyway).
• SQLite is itself a constraint: single-writer, file-locked, in-process. Async I/O only pays off when many cheap queries are in flight in a long-running process. Per-request Laravel and per-file SQLite both fight that model.
• Genuine fit: Amp/Revert CLI daemons, queue workers doing isolated local writes, websocket servers, or a sidecar service — not the main Laravel application tier.

Integration feasibility

• Not a drop-in for Laravel's database layer. Eloquent and the Query Builder assume a PDO connection; this package exposes Amp futures/promises instead. You would hand-roll a repository layer or a custom connection resolver that Laravel's Connection contract cannot cleanly hold.
• Composer resolution is the first real gate: check whether this targets amphp/amp v2 (Loop) or v3 (Revolt). Laravel 10/11 plus Octane (Swoole/OpenSwoole/RoadRunner) bring their own concurrency primitives, and mixing loops is fragile and hard to debug.

Technical risk: high

• 7 stars, 0 dependents, low composite score. This is a personal fork/experiment by Fabien Potencier, not the maintained amphp/sqlite3 under the amphp org. Confirm whether it is a rename, a stale fork, or a divergent rewrite — the answer changes the risk profile entirely.
• No dependents means no field-hardening: no battle reports, no third-party patches, no compatibility shims published by others.
• Write-lock contention surfaces as SQLITE_BUSY; async does not remove the bottleneck, it only moves where you wait.
• Low adoption plus a single maintainer yields a bus factor of one, regardless of that maintainer's reputation.

Key questions

1. Is this an active fork of amphp/sqlite3, or an abandoned personal experiment? Last commit and release dates?
2. Amp v2 or v3? Supported PHP matrix (8.1/8.2/8.3)?
3. Does it bind ext-sqlite3, ext-pdo_sqlite, or shell out to the sqlite3 binary? (Deployment consequence differs sharply.)
4. Feature coverage: WAL, busy_timeout, prepared statements, parameter binding, transactions, cancellation?
5. Has anyone run it under Octane or a Laravel queue worker in production?
6. Is there a security policy or disclosure contact?

Integration Approach

Stack fit

• Poor for standard Laravel HTTP CRUD. Moderate for Laravel queue workers (Horizon) where the job is explicitly concurrent local-SQLite work. Good only inside an Amp-native service where the loop is the application.

Migration path

• Do not migrate existing Eloquent code. Introduce it alongside, scoped to one bounded context (e.g. an import/aggregation worker or a local index) and hidden behind an internal interface so the async primitives never leak into domain code.
• If a Laravel caller must reach it, wrap with a synchronous facade (await/Loop::run) only for batched work — otherwise you have paid the complexity cost for nothing.

Compatibility

• Validate Composer resolution against your pinned Laravel and Octane versions before writing code; expect conflicts with anything that pins Amp majors.
• Confirm the deployment image ships the required SQLite extension and that the SQLite file is accessed by one process class (FPM vs CLI vs Octane worker write from different processes — locking semantics apply either way).

Sequencing

1. Spike (1–2 days): benchmark the actual workload against PDO SQLite. Define kill criteria before starting (e.g. <30% latency gain = stop).
2. Isolate: wrap behind an internal interface; no domain-layer leakage.
3. Pilot: one non-critical background job in staging, with lock-contention and error-path observability.
4. Decide: adopt only if the benchmark is compelling and the maintenance posture clears review; otherwise vendor the code or use upstream amphp/sqlite3.

Operational Impact

Maintenance

• Effectively single-maintainer, low-signal project. Budget for vendoring or an internal fork if adopted; assume upstream fixes may never arrive. Pin exact versions in the lockfile and treat Amp major upgrades as breaking migrations.

Support

• No vendor, no SLA, no LTS. Escalation is internal only. The real cost is cognitive: Amp's futures/coroutines are a distinct programming model from Laravel's synchronous default, requiring code-review discipline on every async boundary.

Scaling

• Async helps only with many in-flight cheap queries in a long-running process. SQLite caps you at one writer; WAL improves read concurrency but does not lift the write ceiling. Horizontal scale means one file per node — a shared network volume is unsafe due to locking. This is a ceiling, not a tuning knob.

Failure modes

• SQLITE_BUSY / lock contention under concurrent writers.
• Accidental event-loop blocking (any sync call, sleep, blocking PDO) stalls every coroutine in the process.
• Unhandled promise rejections or forgotten awaits → silent data loss or swallowed errors.
• Deploy-time drift: missing extension, wrong Amp major, mismatched PHP version.
• Loop conflicts with Octane/Swoole producing deadlocks that are difficult to reproduce and diagnose.

Ramp-up

• Team must learn Amp fundamentals, SQLite concurrency, and Octane interop. Realistic estimate: 3–5 days to a working worker, 4–6 weeks to production confidence — and that assumes the package behaves as documented.

TPM verdict: treat this as a scoped internal experiment, not a platform dependency. For a Laravel shop, PDO SQLite or the canonical amphp/sqlite3 covers the same ground with materially better support and a far lower bus-factor risk.