Predis Compressible Laravel Package

Product Decisions This Supports

• Infrastructure cost / capacity planning: transparent value compression in Redis directly reduces memory footprint per key. This is the lever for deciding whether to scale up an ElastiCache/Memorystore instance, or to fit more working set into the tier you already pay for. Model it as "RAM saved vs. CPU spent," not as a free win.
• Build vs. buy for cache/session plumbing: the alternative is writing and maintaining your own Predis command decorators for set/mset/get/getMultiple. This package is that work, already done, with a command-level test surface. For most teams the in-house version is 200 lines of code plus a permanent tail of edge cases — the mset bug fixed in 1.1 is exactly the kind of edge case you would ship and not notice for months.
• Roadmap input on payload strategy: whether to compress at the client, store smaller serialized payloads, or move large blobs out of Redis entirely. A cheap client-side compression profile is a useful stopgap that buys a quarter of runway while a payload-slimming or tiering initiative is scoped.
• Use cases worth evaluating: session stores with fat serialized user objects, cached API/JSON responses, rate-limiter and feature-flag blobs, and queue payloads — anything routinely above a few hundred bytes where compression ratio actually beats the header overhead.
• Not a decision driver: this release is maintenance. It does not change the capability envelope, so it should not move a roadmap item on its own. It does, however, reduce the "is this maintained?" objection enough to keep the package on the shortlist.

When to Consider This Package

Consider adoption when all of the following hold:

• You are on Predis (not phpredis, not a Laravel Redis abstraction that bypasses Predis' profile/command pipeline). This is a Predis plugin; it does not help a phpredis-based stack, where igbinary/lzf/zstd options already exist at the extension level.
• Your values are consistently large enough to compress — rule of thumb, a few hundred bytes and up. Below that, compression headers and CPU cost more than they save.
• Redis RAM is a real line item and you are closer to a memory ceiling than a CPU ceiling. Compression trades cheap CPU for expensive memory; the inverse situation makes this a pessimization.
• You control every writer and reader for the affected keyspace. Compressed values are opaque to anything that is not running this wrapper — other services, other languages, ad-hoc redis-cli reads, BI exports.
• No server-side value inspection is required — no Lua scripts that read or compare values, no SORT, no ZSET member tricks, no RedisJSON/RediSearch indexing over the payload. Compression makes the value a blob to the server.
• You accept single-maintainer, small-community risk and are willing to pin a version and read the diff on upgrades. 1.1 adding GitHub CI is a genuine maturity signal here; the absence of CI in 1.0 was the main supply-chain concern.

Look elsewhere when:

• You need key compression as well as value compression — this does values only, and key bloat is often the larger problem in high-cardinality caches.
• You need interoperable storage across PHP, Go, Python, or JVM services. A shared, documented serialization/compression contract (e.g. zstd + a versioned envelope) belongs in your own thin layer, not in a PHP-only decorator.
• You want Laravel-native configuration. There is no service provider, no config publish, no facade — you wire the profile into your Predis client yourself. If your team expects config/redis.php to be the whole story, budget an integration task or pick a Laravel-first alternative.
• Predictable tail latency matters more than memory (e.g. a p99-sensitive session path). Benchmark decompression on your real payload distribution before committing; the package cannot tell you what your CPU cost will be.
• You are already hitting Redis Cluster cross-slot or transaction semantics complexity — adding a command decorator that rewrites arguments increases the surface you must reason about during failover and resharding.

How to Pitch It (Stakeholders)

For executives — one paragraph: We are evaluating a small, narrowly scoped add-on to our Redis client that compresses values before they leave the application. The business case is memory cost: Redis pricing is dominated by RAM, and compression typically cuts stored bytes materially for session and cache payloads. It is a one-line integration, not a platform migration, and the risk is bounded because it only touches how bytes are written and read by our own code. The honest caveats are that it trades a little CPU for that memory saving, that the data it writes is only readable by services using the same wrapper, and that it is maintained by a single author — so we would pin the version and treat upgrades as reviewable diffs. Recommendation: pilot it on one non-critical cache and measure bytes-saved against latency before committing.

For engineering — the short version: predis-compressible registers a Predis profile that transparently compresses values on write and decompresses on read, so application code keeps calling set/get/mset unchanged. Version 1.1 is a maintenance release: it adds GitHub Actions CI (closing the biggest gap in 1.0 — no automated verification) and fixes mset, where multi-key writes were not being compressed per-value, producing inconsistent data that would fail on read or silently bypass the memory saving. No new APIs, no breaking changes, no deprecations. Integration is manual — construct your Predis client with the compressible profile; there is no Laravel service provider or config hook. Before adopting: confirm we are on Predis, confirm payload sizes justify it, and audit that no Lua, SORT, or module queries read the affected values server-side. Pin to 1.1 and add a smoke test that round-trips set, mset, and getMultiple through a real Redis instance.