- What does michael-rubel/lada-cache actually do?
- Lada Cache is a Laravel-specific, Redis-backed query cache that transparently intercepts database queries, hashes the SQL plus bindings, and stores the result set in Redis. Entries are tagged by table so writes can invalidate the affected cached queries. It is a cross-cutting data-layer dependency that should be evaluated like infrastructure rather than a normal feature package.
- How do I install lada-cache in a Laravel application?
- Install it with Composer, publish the package config, point it at a Redis connection, and enable caching per database connection. No migrations are needed because the cache is ephemeral. The real effort is not installation but validating correctness across joins, transactions, raw SQL, pagination, and multiple connections.
- Which Laravel, PHP, and Redis versions does lada-cache support?
- The last release was February 2023, so the proven target is the Laravel 9/10 era on PHP 8.1/8.2 with Redis 6/7. There is no ecosystem validation to lean on, since the package has a single maintainer, one star, and zero dependents. Read composer.json and the source before assuming your matrix is supported.
- Does lada-cache work with Laravel 11 and Laravel 12?
- Laravel 11 and 12 compatibility is unproven given the stale release history. Pin the package version and run your own test suite against the exact Laravel and PHP versions you deploy. If you are on Laravel 11 or newer, plan on the possibility that a fork is required.
- How does lada-cache invalidate cached queries when data changes?
- Cached entries are tagged by table name, and write operations flush the tags for the affected tables so stale rows are not served. Automated invalidation is the primary correctness risk in this design. Verify the behaviour yourself for writes inside transactions, raw SQL statements, and multi-tenant scoping before trusting it in production.
- Does lada-cache handle transactions, raw SQL, joins, and aggregates correctly?
- These are the areas that need explicit proof. Build a correctness harness in staging that runs the same operations with caching on and off, then compares results across CRUD, transactions, joins, subqueries, unions, aggregates, pagination, and multiple connections. Do not enable it on connections with heavy raw SQL or read/write splitting until those paths pass.
- What happens if Redis goes down, does lada-cache fail open to the database?
- Whether the package falls back to the database or throws an exception on a Redis failure has to be verified from the source code. Test it directly by stopping Redis in staging and observing request behaviour. Redis becomes a correctness-sensitive dependency here, not just a performance optimisation, so plan a kill switch for rollout.
- Can I use lada-cache alongside response caching or Eloquent caching?
- It can conflict with existing response caching, Eloquent-level caching, or hand-rolled cache-key strategies, so audit those before enabling it. Use a dedicated Redis database or a separate Redis instance so cache eviction pressure does not hit sessions, queues, and application caches. Keep one clear owner for cache invalidation semantics across the stack.
- Is lada-cache safe for multi-tenant apps or Redis Cluster?
- Tag behaviour under Redis Cluster and eviction is a known risk area, as are key collisions and cache stampedes under load. Multi-tenant key spaces need deliberate isolation and testing so one tenant cannot read another tenant's cached rows. Treat these scenarios as unsupported until you have proven them in your own environment.
- Is lada-cache actively maintained, or should I fork it?
- Adoption signals are weak: a single maintainer, no recent release, one star, and zero dependents. Treat it as a fork-and-own candidate rather than a drop-in vendor dependency, and name an internal owner who will carry it through Laravel upgrades. Roll it out as a measured performance experiment behind a kill switch, expanding only after stale-read and invalidation metrics stay clean.