Postgres Laravel Package

Product Decisions This Supports

• Build vs. buy for async DB access: This is a "buy" decision — do not hand-roll a non-blocking PostgreSQL wire-protocol client. amphp/postgres is an MIT-licensed, maintained adapter (last release Feb 2026) on top of the Amp runtime, so the cost is adoption and integration, not R&D.
• Architecture bet on Amp: If a service is going to be built on the Amp event loop (v3, fiber-based, PHP 8.1+), this package is the Postgres adapter that makes that bet viable. It's a foundational dependency, not a feature.
• Enabling a class of features: Long-lived, high-concurrency PHP services — WebSocket servers, SSE/streaming endpoints, queue consumers, API gateways, real-time dashboards — where a synchronous PDO/pgSQL connection per request becomes the bottleneck.
• Scoping async adoption to a bounded context: The practical roadmap decision is "async for this one service, synchronous Laravel everywhere else." This package lets you do that without rewriting the monolith.
• Connection-pool and throughput decisions: Provides connection pooling and prepared statements, so it supports capacity-planning choices (fewer DB connections, more concurrent in-flight queries) rather than raw feature delivery.
• Risk posture: Low financial risk (MIT, no license cost) but ecosystem risk — 107 stars reflects a small, specialized community. Treat it as a contained infrastructure dependency, not a platform-wide standard.

When to Consider This Package

Adopt when:

• You already run, or have decided to run, an Amp-based service and need Postgres.
• The workload is I/O-bound with many concurrent queries (fan-out reads, per-connection WebSocket backends, streaming APIs).
• You need a long-running process to hold pooled connections and multiplex queries without blocking the event loop.
• Your team is comfortable with async/event-loop programming and understands that any blocking call stalls the whole loop.
• You're scoping it into one service or worker rather than the main Laravel request lifecycle.

Look elsewhere when:

• The target is a conventional Laravel app on PHP-FPM or standard Octane — synchronous PDO/pgSQL per request is fine and this adds no measurable value.
• You need Eloquent, the query builder, migrations, or any ORM abstraction — this is a low-level client, and bridging it into Laravel's DB layer is real work with little payoff.
• Your team lacks async experience — the failure mode (a stray blocking call silently freezing all concurrency) is expensive to debug and easy to ship.
• You're standardizing on Swoole/OpenSwoole — that runtime has its own coroutine clients and mixing runtimes creates confusion.
• You need multi-database abstraction, MySQL support, or broad third-party tooling.
• You require a large, well-staffed community for long-term support; 107 stars and a specialized ecosystem mean you largely own your own integration and debugging.
• Your bottleneck is CPU or query design, not connection concurrency — async solves the wrong problem.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed infrastructure component that unlocks a specific, narrow capability — running PHP services that handle many database-backed operations concurrently without one query blocking the rest. It is not a rewrite of the main application and carries no license cost. The real cost is engineering familiarity with async PHP, so the right ask is a time-boxed spike in one bounded service, measured against a concrete throughput or connection-count target, before any broader commitment. Market signal is modest — it's a specialized tool with a small community — so treat it as a contained bet, not a platform standard.

To engineering: amphp/postgres is the mature Postgres adapter for the Amp event loop: non-blocking connections, pooling, prepared statements, and transactions, actively released as of early 2026. It fits when you're building a long-running Amp service where synchronous PDO would serialize your I/O. It does not give you an ORM or Laravel integration, and it demands async discipline — blocking calls in the loop are the primary footgun. If we pursue it, scope it to one service, document the async conventions up front, and benchmark against the synchronous baseline before expanding.