Shared Instances

When running more than one WordPress installation on the same Redis instance, each site must use a separate Redis database. Using prefixes is strongly discouraged because cache flushes will affect all sites sharing the same database, regardless of prefix.

  1. Using Databases
  2. Using Prefixes
  3. Size Display
  4. Data Isolation

Using Databases

For the best performance, it’s recommended to use a different database index 0-15 for each WordPress installation, by using the database configuration option.

By default, Redis has 16 databases. This can be increased in your redis.conf without any performance impacts.

define('WP_REDIS_CONFIG', [
    // ...
    'database' => 0,
]);

Using Prefixes

Using prefixes to share a single database between multiple sites is strongly discouraged. Prefixes prevent data collisions, but cache flushes remain global — if site A flushes the object cache, sites B and C will also be flushed.

The only exception is Redis Cluster, which does not support multiple databases. When using Redis Cluster, each site must have a unique prefix.

define('WP_REDIS_CONFIG', [
    'prefix' => 'mysitename',
]);

Prefixes must be 32 characters or less. For readability avoid special characters and use short, simple strings (apple, apple-jobs) not hashes.

Size Display

By default, Object Cache Pro displays the Redis database size in various places. For technical reasons, this “Redis Memory” number includes all databases, not just the one set using the database configuration option. This can be misleading for end-users, especially after clearing the cache and seeing the “Redis Memory” not drop to (near) zero.

If the instance is shared between multiple sites or users, this confusion can be avoided by using the shared configuration options to display object/key counts, instead of the database bytes.

Data Isolation

ACLs can be used to isolate customers on the same caching server:

ACL SETUSER picard on >secret +@all -@dangerous -select +select|4 +flushdb +keys +info +restore +role

This command will:

  • Create the user picard with the password secret
  • Grant access to @all commands, except @dangerous
  • Limit SELECT access to database 4
  • Grant access to some additional commands like FLUSHDB and INFO

Database 0 is always accessible to all users and cannot be restricted. If shared access in 0 is a concern, a prefix restriction can be used: ~enterprise:*