Think of Drupal's cache system as a restaurant kitchen: instead of cooking every dish from scratch for every customer, a good kitchen preps components ahead of time and reheats them fast. By default, Drupal keeps that "prep station" in your database — every cached item is a database row. That works, but it means every cache read is a database round-trip. Switching the default cache backend to files moves that prep station onto local disk instead, which on many hosts is faster to read from than the database and takes real load off it.
What you'll learn in this lesson
- Why Drupal's cache backend is swappable, and what "backend" actually means here
- How to configure the filesystem-based cache backend via
$settings['cache'] - When file-based caching is the right choice — and when it genuinely isn't
Drupal's cache backend is a swappable interface
Every cache read and write in Drupal core goes through \Drupal\Core\Cache\CacheBackendInterface — get(), set(), delete(), and friends. Core ships with a database-backed implementation (DatabaseBackend) as the default, but because everything is coded against the interface rather than the concrete class, you can swap in a completely different storage mechanism — files on disk, APCu in shared memory, Redis, Memcache — without touching a single line of the module code that calls \Drupal::cache(). This is the same dependency-inversion principle behind Drupal's service container: code depends on a contract, not an implementation.
Configuring the file-based cache backend
Drupal core doesn't ship a dedicated "file cache" backend class out of the box the way it ships the database one — in practice, "file-based caching" on a Drupal site almost always means installing a small contrib module (like Cache Backend File Cache, or a similar package) that provides a CacheBackendInterface implementation backed by flat files, then pointing Drupal at it in settings.php:
$settings['cache']['default'] = 'cache.backend.filecache';
$settings['filecache_directory'] = '/var/cache/drupal/filecache';The $settings['cache']['default'] key is the actual switch — it tells Drupal's service container which service ID to use for every cache bin that doesn't have its own more specific override. You can also override just one bin (like render or page) instead of everything:
$settings['cache']['bins']['render'] = 'cache.backend.filecache';When file-based caching actually helps
File-based caching shines on single-server setups with fast local disk (especially SSD) and a database that's under real load — moving cache reads off the database frees up connections and I/O for the queries that actually need it. It's a poor fit the moment you run more than one web server behind a load balancer: each server would build and maintain its own separate file cache, so one visitor could get a stale (or missing) cached page depending on which server handled their request. That's exactly the problem a shared backend like Redis or Memcache — covered in the next two lessons — is built to solve.
Quick check: you have a two-server, load-balanced Drupal site and someone suggests switching to file-based caching to take pressure off the database. What's the problem with that plan? (Answer: each server maintains its own independent file cache, so cache state isn't shared between them — a page invalidated on server A might still serve a stale cached copy from server B. File-based caching only makes sense for a single-server setup.)
Key takeaways
- Every cache backend in Drupal implements
CacheBackendInterface— swapping backends never requires changing the code that reads or writes cache data. $settings['cache']['default']sets the site-wide default backend;$settings['cache']['bins'][...]overrides one specific bin.- File-based caching reduces database load on single-server setups with fast local disk, but breaks down across multiple web servers since each one keeps its own separate cache.
- A file cache directory on ephemeral/non-persistent storage gets wiped on every deploy or container restart — know your hosting environment before relying on it.
Coming up next
Next, we look at Memcache — a shared, in-memory cache backend that solves exactly the multi-server problem file-based caching can't, at the cost of needing a separate service to run and maintain.