Weave Code
Cache Query Laravel Package
laragear/cache-query
Cache your Laravel Eloquent queries and get fast, consistent results without hitting the database on every request. It hooks into the query builder, so you can cache models, counts, and relationships with a simple chainable call.
Laragear/cache-query brings effortless, automatic caching to Laravel Eloquent queries. Wrap a query with cache() to store results in any Laravel cache store, while the package automatically invalidates entries when underlying models are created, updated, or deleted—no manual keys or observers required.
It integrates cleanly with Laravel’s cache system and keeps cached data fresh across model changes.
- Automatic invalidation on model changes
- Works with any Laravel cache store
- Configurable TTL and cache tags
- Simple
cache()query macro - Laravel-native, zero-config setup
Frequently asked questions about Cache Query
- How do I install and set up laragear/cache-query in a Laravel app?
- Install it with Composer using composer require laragear/cache-query. The service provider is auto-discovered, and you can optionally publish the config file with php artisan vendor:publish. There are no migrations or schema changes. After that, chain ->cache() onto any Eloquent query builder call you want to remember.
- Which Laravel and PHP versions does laragear/cache-query support?
- The package targets modern Laravel applications running PHP 8.x, but the exact constraints live in the repository's composer.json. Check that file against your project before adopting, and confirm the maintainer's stated policy for newly released Laravel majors. Because it hooks into Eloquent internals and Laravel's cache contract, minor-version behavior can change, so validate on your actual Laravel version in staging.
- How does laragear/cache-query invalidate cached queries automatically?
- Results are keyed by the query's SQL and bindings and stored in your Laravel cache store. The package listens to Eloquent model events, so a create, update, or delete on a related model flushes the affected cached results. This means you don't write cache keys or tags by hand. It also means invalidation only works when writes actually fire Eloquent events.
- Does it work with file or database cache stores that don't support tags?
- Tag-based invalidation requires a store that supports tags, such as Redis, Memcached, or the array driver. File and database stores do not support tags, so invalidation will silently degrade there rather than throw an error. For production use, configure Redis or Memcached as your cache store. Always test invalidation behavior on the exact driver you plan to run.
- Which writes will not invalidate the cache and could serve stale results?
- Any write that bypasses Eloquent events can leave stale entries: DB::table() queries, raw SQL, query-builder update() or upsert() calls in some Laravel versions, certain pivot attach and detach paths, and writes from other services sharing the same database. These failures are silent, with no error or log entry. If your domain requires strong read-after-write consistency or writes through the query builder for performance, this package is a poor fit.
- How are cache keys built, and are they scoped per tenant, connection, or user?
- Keys are derived from the generated SQL plus its bindings, which makes identical queries share an entry and differently bound queries distinct. This does not automatically guarantee tenant, connection, or auth scoping in every setup, so treat multi-tenancy as something you must verify. A practical approach is to ensure tenant or user identifiers appear in the query bindings so keys diverge naturally. Watch for key length limits on Redis and Memcached with very long SQL.
- Is laragear/cache-query safe to use with Laravel Octane and queue workers?
- It should work with Octane and queue workers as long as the cache store is shared and key generation is deterministic across processes. Because invalidation depends on model events, writes performed inside queued jobs must go through Eloquent for the flush to happen. Confirm Octane compatibility explicitly on your version matrix before rolling it out broadly.
- Does it provide stampede protection or configurable TTLs?
- The package is built around event-driven invalidation rather than TTL juggling, so you don't manage expiry per query. Stampede protection on cold keys is not a documented strength, so high-traffic keys can still see a thundering herd after a flush. Wrap critical paths with a Laravel cache lock or warm the cache after deploys. Also consider memory characteristics when caching very large result sets.
- Is laragear/cache-query production-ready, and what are the alternatives?
- It is architecturally low risk and fits read-heavy, low-write domains like catalogs, CMS content, reference data, and dashboards in a standard Laravel monolith. Commercial risk is real but bounded: roughly 272 GitHub stars, no Packagist dependents, and a single-maintainer profile mean limited third-party production validation, though the MIT license permits forking. Alternatives include Cache::remember with manual keys and tags, or HTTP response caching packages. Introduce it behind a repository or query-scope layer and diff cached versus uncached results in staging first.
- How do I disable laragear/cache-query or roll it back safely?
- Adoption is purely additive and reversible: removing the ->cache() calls or disabling the package via config restores uncached behavior. There are no migrations to roll back and no data to clean up. You can also uninstall the Composer package without side effects beyond losing the caching. Start with one read-heavy endpoint, expand model by model, and keep the rollback path documented for your team.
Weaver
How can I help you explore Laravel packages today?