Weave Code
Laravel Model Caching Laravel Package
mike-bronner/laravel-model-caching
Automatic query caching for Laravel Eloquent models. Cache query results and relationships, then invalidate cached data automatically when models change, reducing database load and speeding up repeated reads with minimal code changes.
Eloquent model-caching made easy.
Frequently asked questions about Laravel Model Caching
- How do I install laravel-model-caching in a Laravel app?
- Install it with Composer using composer require mike-bronner/laravel-model-caching, then add the Cachable trait to each Eloquent model you want cached. The package works as a drop-in optimization, so no service provider or config changes are required for basic use. Admit it per model rather than applying it as a blanket default.
- Which PHP and Laravel versions does laravel-model-caching 13.2.0 support?
- Version 13.2.0 requires PHP 8.3 or higher; PHP 8.2 is dropped, and Composer will keep teams on 13.1.11 unless the runtime is upgraded. Confirm your Laravel version against the package's composer.json before upgrading. Treat the PHP 8.3 floor as a planned upgrade item, not a routine version bump.
- How does laravel-model-caching invalidate cached queries automatically?
- It hooks into Eloquent model events and clears the cache tags associated with a model when that model is created, updated, or deleted. This event-based invalidation is what keeps cached query results and relationships from going stale after writes. TTL caching added in 13.2.0 can act as a backstop, but it does not make write-heavy or read-after-write-consistent paths suitable.
- Can I configure a TTL for cached models in laravel-model-caching?
- Yes. Version 13.2.0 added global and per-model TTL caching, so you can give a model a bounded staleness window as a backstop under event-based invalidation. This widens the package's fit to read-heavy models with a defensible staleness SLA. It still does not make write-heavy models a good fit.
- What breaking changes are in laravel-model-caching 13.2.0?
- The release raises the PHP floor to 8.3, changes the cache property to a typed protected bool $isCachable, and removes newBaseQueryBuilder() from the trait, so local traits or models redeclaring those can fatal at class load. It also changes modelCache:clear so it no longer empties the entire cache store, and it changes many cache keys and tags, so expect a one-time cold cache after deploying. Read the upgrade notes and grep your codebase before rolling it out.
- Is laravel-model-caching safe for write-heavy models?
- No, it is intended for read-heavy models where a bounded staleness window is acceptable. Write-heavy models and paths that require read-after-write consistency remain unsuitable because invalidation is coarse and event-based. Evaluate the read/write ratio per model and admit caching selectively.
- Does laravel-model-caching cache relationships and pivot tables?
- Yes, it can cache query results and relationships, including many-to-many eager loads. Version 13.2.0 fixed several relationship-heavy invalidation bugs, including pivot-table tagging and where-subquery joined-table tagging. Older 13.1.x releases could return incorrect results in some of these cases, so 13.2.0 should be your floor.
- Why does modelCache:clear no longer flush the whole cache store?
- In 13.2.0 the command was changed to avoid wiping an entire cache store when the configured prefix is empty, which closes a genuine footgun for Redis users. If you have operational scripts that relied on it as a general flush, add php artisan cache:clear to those scripts. The narrower blast radius is intentional, but it changes existing runbooks.
- What are the main risks of using laravel-model-caching?
- The main risks are builder decoration conflicts with other packages, unbounded cache key cardinality in Redis, and coarse per-model invalidation. The 13.2.0 release also demonstrated churn in builder internals, so pin exact versions and stage upgrades rather than floating constraints. Verify caching behavior per code path against the source, because the README has been an unreliable specification.
- How should I test or upgrade laravel-model-caching in production?
- Pin an exact version, treat 13.2.0 as the minimum, and assume a one-time cold cache on deploy day as a capacity event. Grep for redeclarations of $isCachable and newBaseQueryBuilder, and revert any local workarounds for the removed method. Because documentation has been wrong about what is cached, validate each cached code path against the actual code in staging before rollout.
Weaver
How can I help you explore Laravel packages today?