Amphp Sqlite3 Laravel Package

Product Decisions This Supports

• Async PHP runtime investment. Whether to move parts of a service onto an event-loop stack (Amp, ReactPHP, Swoole, FrankenPHP worker mode). A non-blocking SQLite driver is one of the gating dependencies for that migration, so evaluating it de-risks a much larger architectural bet.
• SQLite as system of record vs. cache/scratch space. The absence of a good async driver has historically ruled SQLite out for long-running single-process services. A credible one reopens "Postgres vs SQLite" for internal tools, on-prem/edge deployments, and per-tenant embedded storage — often a significant ops-cost saving.
• Build vs. buy vs. adopt. The alternatives are a synchronous PDO/SQLite3 wrapper, a hand-rolled worker-process shim, or a different driver. This package is cheap to try and cheap to rip out, which is exactly the profile of a reversible spike rather than a platform commitment.
• Local-first and offline-capable features. Per-user local databases, sync-on-reconnect flows, embedded analytics, and latency-sensitive read paths that shouldn't cross a network.
• Test and CI infrastructure. Faster, container-free database fixtures for async test suites — a small but frequently measurable reduction in CI time and flake.
• Dependency risk register. With 7 stars, 0 dependents, and a single maintainer, this belongs on the "watch, don't build on" list until adoption or an internal fork commitment exists.

When to Consider This Package

Adopt or spike when:

• Your PHP process is long-lived — an Amp/ReactPHP/Swoole worker, a websocket server, a queue consumer, a CLI daemon — and blocking disk I/O is measurably hurting p95 latency or per-worker throughput.
• You want zero-infrastructure persistence (embedded, on-prem, single-node, CI) and have confirmed SQLite's single-writer model fits your write pattern.
• You are already inside the Amp ecosystem, where sharing the event loop, cancellation, and error semantics with amphp/http-server or amphp/mysql is where the value compounds.
• You can run a time-boxed evaluation (2–5 days) and can absorb replacing the driver if it stalls.
• Licensing matters: MIT, no copyleft or commercial entanglements to review.

Look elsewhere when:

• You're on classic PHP-FPM request/response. Async buys you nearly nothing; PDO SQLite or a real RDBMS is simpler and faster to reason about.
• Write concurrency is high or multi-process. SQLite serializes writers; async removes blocking on the caller's side, not the storage engine's constraint. Move to Postgres/MySQL.
• You need replication, failover, row-level access control, or an ops story a DBA can own.
• You require a support contract, security-response SLA, or maintainer headcount. 7 stars and 0 dependents means a bus factor of one, regardless of the author's standing.
• The team lacks async/fiber experience and can't absorb the debugging cost of event-loop code.
• You haven't yet verified internals: how it bridges PHP's blocking sqlite3/PDO extension (worker process, fibers, something else), which Amp major version it targets, and whether prepared statements, transactions, and busy-timeout handling are covered.

How to Pitch It (Stakeholders)

Executives: This is a small, permissively licensed building block that lets our PHP services use an embedded database without stalling other work in the process. It makes SQLite a credible option for single-node, on-prem, and internal-tooling scenarios — often the cheapest form of persistence we can ship. I'd frame it as an evaluated component, not an approved dependency: it's early-stage and effectively single-maintainer. Recommend a gated pilot — one service, one quarter — with a documented fallback to PDO, rather than a roadmap commitment.

Engineering: The upside is concrete: non-blocking SQLite access inside an Amp event loop, consistent concurrency and cancellation semantics with the rest of the ecosystem, MIT license, and no runtime services to operate. The caveats are equally concrete: no community to lean on, and it does not change SQLite's single-writer constraint — it only removes blocking from the caller's side. Approve a spike with four exit criteria: (1) verified driver approach and Amp version support; (2) a load test showing measurable p95 or throughput improvement over PDO in our actual worker; (3) transaction and error-path coverage we trust, including busy/locked handling; (4) a written fallback plan, so swapping to sync PDO or Postgres stays a days-not-quarters exercise. If any criterion fails, we wrap it in our own interface or skip it — we don't adopt it directly.