Igbinary is now the default object-aware serializer when the extension is available

Drupal core now ships an additional serializer, Drupal\Component\Serialization\IgbinarySerialize, registered as the serialization.igbinary service. This service is now bound to the Drupal\Component\Serialization\ObjectAwareSerializationInterface alias, replacing the previous binding to serialization.phpserialize.

When the igbinary PHP extension is installed, payloads written by the database cache backend (cache.backend.database) and the expirable database key/value store (keyvalue.expirable.database) are encoded with igbinary, which is faster to decode and produces smaller payloads than PHP's native serialize(). When the extension is not installed, IgbinarySerialize transparently falls back to serialize()/unserialize(), so no configuration is required and sites without the extension behave as before.

IgbinarySerialize distinguishes its payloads from plain serialize() output using an internal binary prefix, so existing rows written by older Drupal versions remain decodable after upgrade. There is no data migration; legacy rows are simply re-encoded with igbinary the next time they are written.

The serialization.phpserialize service is unchanged and still available for code that explicitly needs PHP's native serialize().

Note: This change concerns the object-aware serializer used by cache and key/value storage. It is unrelated to the serializer service from the serialization module (Symfony Serializer used by REST/JSON:API), and unrelated to serialization.json / serialization.yaml, which handle text formats.

What contrib and custom code should do

If you inject the serializer, prefer the interface, not a concrete service ID. Doing so makes your code respect whatever core or the site has chosen as the default, and lets sites swap implementations without patching you.

Recommended

Inject by the interface — autowiring picks up the current default automatically:

use Drupal\Component\Serialization\ObjectAwareSerializationInterface;

public function __construct(
  private readonly ObjectAwareSerializationInterface $serializer,
) {}

Or, if you write services.yml by hand, reference the interface as the service ID:

my_module.thing:
  class: Drupal\my_module\Thing
  arguments: ['@Drupal\Component\Serialization\ObjectAwareSerializationInterface']

Discouraged

Do not hard-code @serialization.phpserialize if your intent is "the default Drupal serializer." That ID still resolves to plain PHP serialize() and will not benefit from igbinary even on hosts where it is available. Only reference it explicitly when you specifically need PHP's serialize() format (for example, when interoperating with stored payloads outside Drupal that you know are plain PHP-serialized).

Likewise, do not hard-code @serialization.igbinary unless you specifically require the hybrid igbinary-or-fallback behavior. Pinning to a concrete service prevents sites and contrib from substituting their own implementation through the interface alias.

Why no serializer.default alias?

The interface (Drupal\Component\Serialization\ObjectAwareSerializationInterface) already serves as the canonical way to refer to "the default object-aware serializer." Adding a second alias such as serializer.default would only duplicate what the interface alias already provides and split contrib between two equivalent spellings. The interface alias is the documented contract; everything that wants the swappable default should depend on it.

Replacing the serializer entirely

To replace the default with your own implementation site-wide, override the alias in a ServiceProvider or services.yml, e.g.:

services:
  Drupal\Component\Serialization\ObjectAwareSerializationInterface: '@my_module.my_serializer'

Any consumer that injects the interface — including core's database cache and expirable key/value backends — will pick up the replacement.

Affected core consumers

The following core services were updated to inject the interface rather than @serialization.phpserialize:

• cache.backend.database (Drupal\Core\Cache\DatabaseBackendFactory)
• keyvalue.expirable.database (Drupal\Core\KeyValueStore\KeyValueDatabaseExpirableFactory)
• The early-bootstrap cache container in Drupal\Core\DrupalKernel (uses serialization.igbinary directly because the bootstrap container is built before the full alias graph)

BC and upgrade notes

• No update path is required. Existing serialized rows in cache_* and key_value_expire tables remain readable.
• Sites without the igbinary extension are not affected at runtime; encoding falls back to serialize().
• No public API was removed or deprecated.