AntV's avatar
Level 6

Status of Cache Tags in laravel 12

I've noticed that after two versions of it being absent from the documentation, Cache tags reappeared.

I tried searching to whether that means that the/most/some issues have been fixed but I did not find anything. The way it is written with no warning (other than it won't work on most drivers) makes me hopeful that it only means that they should work as intended.

Has anyone any idea as to whether they are ok to use now or are they still better avoided?

0 likes
11 replies
LaryAI's avatar
Level 58

Cache tags in Laravel 12 are now officially documented again, as you noticed. Here’s the current status and best practices as of Laravel 12:

1. Supported Drivers

Cache tags only work with the following cache drivers:

  • redis
  • memcached
  • dynamodb
  • (Not supported: file, database, and array drivers)

If you use cache tags with an unsupported driver, Laravel will throw an exception.

2. Issues and Fixes

The main issues reported in the past were related to tag invalidation and performance. The main problematic driver was file (and sometimes database). These problems were a key reason tags disappeared from the documentation.

Since Laravel 12, the framework has:

  • Hardened cache tag support specifically for the drivers mentioned above.
  • Made it more explicit in the documentation that tags are only for certain drivers.
  • Older problems with tag performance and reliability on supported drivers have largely been resolved.

3. When To Use

  • If you are using one of the supported drivers (redis or memcached are most common), it’s safe and recommended to use cache tags.
  • Always avoid attempting to use tags on unsupported drivers—this will throw an error.

4. Usage Example

Here’s a basic example for Redis:

Cache::tags(['users', 'admins'])->put('user:1', $user, 3600);

$user = Cache::tags(['users', 'admins'])->get('user:1');

// To flush all cache items tagged with "users"
Cache::tags(['users'])->flush();

5. Summary

Cache tags are safe and encouraged to use in Laravel 12 as long as you stick to supported cache drivers (like Redis). There’s no lingering warning about bugs when you do this, and they’re a powerful way to manage grouped cache entries.

References:

In summary:

Use cache tags on supported drivers in Laravel 12 — they are fully supported and stable in those contexts. For file, database, or array drivers, do not use tags.

Glukinho's avatar

I think if something is in the official documentation you can rely on it.

AntV's avatar
Level 6

One would think so, yes, but if you search around you will find quite a lot of backlash regarding tags in previous versions, and from my understanding current tags support does not fail gracefully on unsupported drivers, instead it produces errors. Having said that, I have decided to avoid them for now, just the hustle of having to setup Redis or memcached even for local seems more of a pain than having to live without them.

ian_h's avatar

Cache tags work (if you're using Redis for example), even in 12. I implemented these last week in project. Just take heed of what caching backends do/don't work and if you're using something that does, you should be good to go.

Vincent Schmalbach also wrote a blog post about some reasons for not using cache tags (some are valid, depending on your implementation) and also offers a solution to implement your own tagging. I haven't used the approach, but I bookmarked this post a few weeks ago when I knew I was going to be looking at caching with tags for certain things and found that the docs had been removed, as I also used the Laravel tagging in a previous Laravel 10 project and the docs were there.

AntV's avatar
Level 6

This blog post was what started me questioning whether I should use them or not. Since the main reason for tagging is to be able to mass flush, I think I'd rather avoid the headache of having to setup Redis for each environment (at least for now) and write some custom logic to mass delete caches based on their key. I think I may have been spoiled by how well other facades handle different implementations 😅

ian_h's avatar

That's a fair approach! Everything in life is a series of compromises.. and if setting up and maintaining redis is required for this in your situation, I think I might also come to the same conclusion and come up with something "simpler" and more self-contained.

ian_h's avatar

Coming back to this... cache tagging isn't something I would rely on, it's just come around to bite me on the arse! It seems to point to an issue with the flush() method if you use that to bulk delete entries rather than a forget() call to a single key.

This fails for example:

Cache::tags(['my-tag'])->put('demo-key-01', 'some-data-01');
Cache::tags(['my-tag'])->put('demo-key-02', 'some-data-02');

Cache::tags(['my-tag'])->flush();

You would expect that both the demo-key-01 and demo-key-02 entries to be removed, but alas, neither are, resulting in a broken cache implementation if you're hoping for bulk removal.

ian_h's avatar

Aaaand back again. This isn't actually a Laravel bug itself, this stems from the phpredis client that is Laravel's default Redis client.

Rebuilding my docker container with the dependencies required by Cachewerk's Relay client and swapping out the REDIS_CLIENT in the .env to use relay instead, this works as expected 😃

Please or to participate in this conversation.