Laravel Redis Connection Clients Laravel Package

Product Decisions This Supports

• De-risking Redis client migrations. The package lets a single connection (or cluster) opt into a different Redis client via a client key in config/database.php, while every other connection keeps database.redis.client. This turns a big-bang phpredis ↔ predis swap into an incremental, connection-by-connection cutover — directly supporting decisions like "can we adopt the newer client extension for cache but keep queues on the proven one?"
• Mixed-client fleets as a first-class option. Teams often want different clients for different workloads (cache vs. queues/sessions vs. a geo-replicated cluster), or a custom client registered through Redis::extend() for a single connection (TLS/proxy wrapper, instrumented client, cluster-specific handling). This release makes that a configuration decision rather than an application-code change.
• Build vs. buy. The surface area is deliberately tiny — per-connection override of one config value. Inlining this in a service provider is plausible; the package's value is packaging, docs, and version tracking. Weigh the maintenance burden of a single-purpose dependency against ~tens of lines of in-house glue.
• Roadmap enablement. Useful wherever only some connections are compatible with a target client version (e.g., cluster support gaps, extension upgrades, or a new client we want to trial on one workload first). It also supports per-connection observability or proxying clients without rewriting database.php globally.
• Use cases: phased PHP extension upgrades, multi-tenant or sidecar Redis endpoints, piloting a custom Redis::extend() client on one connection, and any environment where a global client setting is too coarse.

When to Consider This Package

Adopt when:

• You need per-connection Redis client selection and are on Laravel 12 or 13 with PHP 8.3+ (hard requirement).
• You're mid-migration between phpredis and predis and cannot do a flag-day cutover.
• You have a custom client registered via Redis::extend() that should apply only to specific connections.
• The alternative is a global database.redis.client change that would affect every connection — i.e., the blast radius matters to you.

Look elsewhere or wait when:

• Maturity is a concern. This is v0.1.0; expect API/config semantics to be unproven at scale. Pin the version and be prepared to vendor or fork the (small) code.
• Your need goes beyond client — e.g., per-connection serializer, prefix, timeouts, or persistence options. The scope here is narrow by design; confirm it covers only what you need.
• You're on Laravel < 12 or PHP < 8.3 — unsupported.
• You have no immediate migration or mixed-client requirement; in that case the package adds a dependency for a scenario you don't yet have.
• You want broad ecosystem/community backing; a v0.1.0 single-purpose package is unlikely to have it yet.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk enabler for infrastructure modernization. It lets us change Redis drivers per connection instead of all at once, which reduces cutover risk, downtime, and rollback cost during client or extension upgrades. The dependency is narrow in scope and configuration-only — no application logic changes. The trade-off is maturity: it's a first release, so we pin the version and treat it as a thin, replaceable layer rather than a strategic dependency.

For engineering: Configuration-only change — add a client key to a Redis connection or cluster in config/database.php and only that connection uses it; everything else continues to honor database.redis.client. Works with phpredis, predis, and any client registered via Redis::extend(). Requires Laravel 12/13 and PHP 8.3+. Caveats: v0.1.0 — verify against our Laravel/PHP versions, confirm our custom clients register cleanly, and be ready to vendor or fork if the package stalls. The implementation is small enough that in-housing remains a viable fallback if the dependency becomes a maintenance concern.