Postgres Laravel Package

Technical Evaluation

Architecture fit — poor-to-moderate as a "Laravel package," good as an isolated async data path. amphp/postgres is not a Laravel package. It is a low-level, non-blocking PostgreSQL wire-protocol client for the Amp v3 ecosystem (Fibers + revolt/event-loop). It ships no service provider, no facade, no Eloquent driver, no query builder, no migration integration, and no DB::listen hooks. Laravel's persistence layer is PDO-based and synchronous by design. There is no supported path to "swap the driver" — integration means running a parallel data access path in a process whose control flow is owned by the Revolt loop.

The honest architectural read: this is viable only where you can carve out a bounded async context — a long-running daemon, a fan-out aggregator, a LISTEN/NOTIFY consumer, a websocket/SSE service — that does not need Eloquent, transactions spanning the sync/async boundary, or Laravel's query observability. Inside a normal FPM request or a standard Octane worker, dropping Amp in inverts the execution model and buys nothing.

Integration feasibility — technically straightforward, organizationally expensive.

• composer require amphp/postgres pulls Amp v3 + Revolt; PHP 8.1+ is satisfied by current Laravel.
• Fibers are cooperative, not preemptive: any PDO call, sleep(), or filesystem read inside the loop stalls all concurrent Postgres work in that process. Mixed sync/async code in one process is the primary footgun.
• Octane supports Swoole and RoadRunner, not Revolt. Running Revolt inside Swoole coroutines is unsupported territory. Treat the async path as a separate entrypoint (Artisan command / standalone binary), not an Octane driver.
• Transaction and pool semantics are manual: you acquire a connection from the pool, and every BEGIN/COMMIT/ROLLBACK and release is your responsibility across fiber suspensions. Laravel gives you none of this for free.

Technical risk — concentrated in duplication and semantics, not in the library itself.

• Two data-access stacks, two connection pools, two sets of conventions, two testing stories.
• Correctness risk around transactions held across suspension points, pool exhaustion, and unreleased connections under exceptions.
• Loss of Laravel-native operability: no query log, no DB::transaction retry-on-deadlock, no model events, no factories, no Telescope visibility.
• Ecosystem lock-in to Amp's release cadence (v2→v3 was a hard break); a future major would strand the integration.
• Low community surface: ~107 stars and a 2.41 opportunity score signal a narrow, specialist audience. Bus factor and Stack Overflow coverage are genuinely thin.

Key questions before approval

1. What is the actual bottleneck — connection count, I/O fan-out latency, or CPU? If it is not I/O concurrency, this library solves nothing.
2. Can the async workload be isolated to one service/command with its own process, or does it need to share transactions with Eloquent?
3. Is PostgreSQL the only datastore on that path? A polyglot path doubles the duplication cost.
4. Who on the team has shipped Fiber/Amp code, and what is the on-call story when the loop wedges at 3am?
5. What is the measured delta versus (a) more PHP-FPM workers, (b) Octane + Swoole concurrency, (c) pgbouncer + tuned PDO pools? Any of these may deliver the same throughput with zero new architecture.
6. What is our exit plan if Amp publishes a breaking major?

Integration Approach

Stack fit. Suitable as a sidecar data path, not as a Laravel DB driver. Keep Laravel/PHP-FPM or Octane-Swoole for the request/response surface and Eloquent; confine amphp/postgres to processes where the Revolt loop is the top-level owner and no PDO handle is ever opened.

Migration path. Do not migrate. Add. A credible first increment:

1. Spike: one Artisan command under revolt/event-loop that opens a pool, runs a representative fan-out query set (e.g., 200 concurrent small queries), and is benchmarked against the same workload on PDO + pgbouncer.
2. If the spike wins on p95 and connection count, wrap access behind a narrow repository interface (e.g., AsyncReportRepository) with a PDO implementation as the fallback, so the rest of the app is unaware of which is in use.
3. Promote only that one use case. Leave the rest of the application on Eloquent.

Compatibility. PHP 8.1+ and current Laravel versions are fine at the language level. Real incompatibilities are runtime: Revolt vs. Swoole in the same process, PDO/blocking calls inside fibers, and any package that assumes DB:: is the only way to reach Postgres. Audit middleware and service providers that touch the DB before running them in an async process.

Sequencing.

• Phase 0 (1–2 days): spike + benchmark + written go/no-go against the Swoole/pgbouncer baselines.
• Phase 1 (1–2 weeks): one isolated async service, repository interface, pool sizing, health check, structured logging, LISTEN/NOTIFY if that is the actual driver.
• Phase 2: observability — query timing, pool saturation, loop lag, unhandled-rejection alerting — before any second use case is considered.
• Explicit non-goal: replacing Eloquent, migrations, or the default connection.

Operational Impact

Maintenance. The library itself is small, MIT, single-purpose, and actively released (latest 2026-02-25), so per-version maintenance is low. The maintenance cost is the integration: pool configuration, transaction discipline, and keeping the Amp/Revolt versions aligned with the rest of the dependency graph. Budget a recurring, non-trivial line item rather than a one-off.

Support. Community-only, small maintainer pool, low star count. No commercial backing. Internal ownership must be explicit — a named engineer, not "the platform team." Assume Stack Overflow will not answer your pool-exhaustion question.

Scaling. Genuinely strong where it applies: one process can service many concurrent queries without a thread or process per connection, which meaningfully reduces pressure on Postgres max_connections and enables high-fan-out aggregation and pub/sub workloads that are awkward on PDO. Scaling caveats are on you: pool size must be tuned against Postgres connection limits across all consumers, and throughput is capped by the single-threaded event loop — CPU-bound work on the async path is a regression, not a win.

Failure modes to instrument for.

• Loop stall from an accidental blocking call — manifests as globally elevated latency with no DB error.
• Pool exhaustion / connection leak when an exception bypasses release; requests hang rather than fail fast. Enforce acquire timeouts and finally-based release.
• Transaction leak across fibers leaving connections in idle in transaction, blocking vacuum.
• Unhandled async errors that silently kill a task, or an uncaught throwable that terminates the whole loop and drops every in-flight query.
• Absence of Laravel-level deadlock retry and backoff — you reimplement it or you absorb the errors.

Ramp-up. Moderate-to-high. Developers fluent in Eloquent and PDO must learn cooperative concurrency, fiber suspension points, structured concurrency, and manual pool/transaction lifecycle. The failure modes are non-obvious and intermittent, which is the worst combination for on-call. Plan for a written internal pattern doc and paired review on the first service.

Recommendation posture. The score (9.28) reflects a well-built library; the opportunity score (2.41) reflects a narrow one. Approve behind a spike with a hard gate: measurable p95 or connection-count improvement over Octane-Swoole and pgbouncer baselines, plus a bounded async context with no Eloquent dependency. Reject if the motivation is general modernization rather than a specific, measured I/O-concurrency bottleneck.