Predis: a pure PHP Redis client for clusters, sentinels and TLS

The problem Predis solves for PHP applications

PHP has two common ways to talk to Redis: the phpredis C extension and a client written in PHP itself. Predis takes the second route. That choice determines who it is for. If your deployment pipeline cannot compile or enable a PHP extension, or if your hosting provider ships a fixed PHP build, a pure PHP client removes an entire class of infrastructure work. The README states support for Redis from 3.0 to 8.0, and the project describes itself as a Redis and Valkey client for PHP 7.2 and newer.

The second problem is topology. A single Redis host is easy; a sharded keyspace, a redis-cluster, or a master with replicas behind sentinel is where most clients get thin. Predis bundles all three aggregation modes behind one client class, plus key prefixing, pipelining, transaction and CAS abstraction, Lua scripting with automatic EVALSHA or EVAL selection, and iterator-based SCAN, SSCAN, ZSCAN and HSCAN. For a PHP team that would otherwise hand-roll failover logic, that breadth is the reason to pick it over a minimal client.

How Predis connects, aggregates and prefixes keys

The client is constructed from connection parameters. Pass nothing and it assumes 127.0.0.1 on port 6379, with a 5 second default timeout for connect(). Pass a named array or a URI string and you override host, port, scheme, credentials and TLS options. Connections are established lazily on the first command, which means constructing a client is cheap and a misconfigured host only fails when a command actually runs.

Aggregation is the interesting part. When you supply an array of connection parameters plus an option telling the client how to combine them, Predis can treat them as a cluster, a replication set, or custom logic you define. The repository ships examples/custom_cluster_distributor.php, examples/replication_simple.php, examples/replication_sentinel.php and examples/replication_complex.php, which map directly onto those modes. Client-side sharding uses pluggable keyspace distributors, so the rule that decides which node owns a key is replaceable rather than hard-coded. Transparent key prefixing applies a configurable prefix strategy across commands, which is useful when several applications share one Redis instance.

Two mechanics are worth calling out because they change behaviour. Pipelining is documented for single nodes and for client-side sharding clusters, not for redis-cluster; if you assume otherwise you will be surprised. And the Lua abstraction chooses EVALSHA or EVAL automatically, which means a script cache miss is handled for you rather than surfacing as a NOSCRIPT error.

Installing Predis and running a first command

The README points at Packagist and Composer. One command adds the dependency, and Composer's autoloader handles the PSR-4 loading, so no require statements are needed in application code.

composer require predis/predis

After that, the smallest useful client connects to the local default instance and issues a SET followed by a GET. The README gives exactly this shape, and the values you should see are the string you wrote and the same string read back.

$client = new Predis\Client();
$client->set('foo', 'bar');
$value = $client->get('foo');

For a real server you supply a named array, which the README calls the preferred form. Named arrays matter because URI strings cannot express every parameter cleanly.

$client = new Predis\Client([
    'scheme' => 'tcp',
    'host'   => '10.0.0.1',
    'port'   => 6379,
]);

Encrypted connections use the tls scheme with an ssl array. The README's example passes a CA file and enables peer verification, which is the setting to keep on unless you have a specific reason not to.

$client = new Predis\Client([
  'scheme' => 'tls',
  'ssl'    => ['cafile' => 'private.pem', 'verify_peer' => true],
]);

If your project has no autoloader at all, the README documents a fallback: require Predis/Autoloader.php and call Predis\Autoloader::register(). That path exists for scripts and legacy projects, not for normal Composer users.

Where Predis is the wrong tool

The honest limitation is the language. A client written in PHP performs the RESP parsing, command serialisation and connection handling in userland, while phpredis does that work inside a C extension. The README makes no performance claim in either direction, and the repository contains no benchmark numbers, so anyone quoting a percentage is quoting something else. The practical consequence is that if your application issues a very high volume of small commands and you control the PHP build, phpredis is the conventional choice and the comparison is one you should measure on your own workload rather than assume.

There are narrower gaps too. Pipelining is documented for single nodes and client-side sharding clusters but not for redis-cluster, so a cluster-heavy workload loses that optimisation. The stated Redis version range is 3.0 to 8.0; a server outside that range is not covered by the README's claim. And the feature list includes Hinted Hash Templates with HIMPORT, which the README ties to Redis 8.10 and describes as automatic per-connection fieldset replay. That is a newer surface than the rest of the client, so treat it as the part most likely to change between minor releases.

Predis against phpredis: two different designs

The comparison people actually search for is Predis versus phpredis, and the difference is architectural rather than a matter of feature checklists. phpredis is a PHP extension. It is installed at the system level, loaded through php.ini, and its command surface follows the extension's own API. Predis is a library. It arrives through Composer, lives in vendor/, and its API is PHP classes you can extend: custom connection classes for different network or protocol backends, custom commands, and overrides of the default commands.

That extensibility is the real dividing line. If you need to intercept commands, swap the connection backend, or define a command the client does not ship, Predis gives you documented seams. If you need the lowest per-command overhead and your environment permits extensions, the C client wins on that single axis. Neither choice is universal, and the repository does not argue the point for you.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-17. Recent releases follow a steady cadence: v3.5.1 on 2026-06-11, v3.6.0 on 2026-08-14, and v3.6.1 on 2026-09-17, the same day as the last push. The presence of CHANGELOG.md, a VERSION file, phpunit.xml.dist, phpstan.dist.neon and a PHP CS Fixer config suggests the project runs static analysis, unit tests and a code style check as part of its routine.

For upgrade cost, the practical signal is the minor version line. Patches and minors within 3.x are the normal upgrade path, and the CHANGELOG is where you check whether a behaviour you depend on moved. There is one file in the repository root that deserves attention before you plan an upgrade: phpunit.relay.xml, alongside examples/relay_connection.php, examples/relay_events.php and examples/relay_compression.php. That indicates a second connection path with its own test configuration, so a relay-based deployment should be tested separately from a plain TCP one.

The licence is MIT, which in practice means you can use the library in closed-source and commercial applications provided you keep the copyright notice and permission notice. This is a description of the licence text, not legal advice; have your own counsel review it if the distinction matters to your organisation.

Editorial conclusion

Adopt Predis when your application already runs on PHP and you need one client that can talk to a single node, a sentinel-managed replica set or a redis-cluster without adding a compiled extension to your build. Skip it if your workload is dominated by raw command throughput and you can install phpredis, since a pure PHP client pays for the protocol work in userland. Before committing, verify three things against your own servers: that your Redis or Valkey version falls inside the 3.0 to 8.0 range the README states, that your deployment can reach the nodes with the scheme you intend to use (tcp, tls or unix), and that your application code passes the connection parameters as a named array rather than an URI string if you rely on options the URI parser does not carry. The repository's own tests and the examples directory are the fastest way to confirm a given topology works before you wire it into production.

Frequently asked questions

Official sources

1. License: MIT
2. predis/predis on GitHub
3. Project website
4. README
5. Releases