- How does Lada Cache actually cache Laravel database queries?
- Lada Cache registers a Lada-aware connection through DB::extend(), so Eloquent and Query Builder queries pass through a custom query builder instead of hitting the database directly. That builder intercepts the SQL, builds a cache key from the SQL, bindings, and database name, and serves matching results from Redis. Granular invalidation runs automatically when data changes, so only affected rows or tables are cleared. After setup, no code changes are required beyond adding the trait to a shared base model.
- How do I install spiritix/lada-cache in a Laravel application?
- Install the package with Composer, publish its config file, and add LadaCacheTrait to a shared BaseModel so your Eloquent models inherit caching behavior. Laravel package discovery registers the service provider automatically. You then tune table includes and excludes, TTLs, and key prefixes in the published config. Because integration happens at the database connection layer, existing Eloquent and Query Builder code paths are cached without modification.
- Which Laravel and PHP versions does Lada Cache support?
- Lada Cache 6.x targets Laravel 12 and 13 on PHP 8.3 or newer, while the 5.x line covers Laravel 9 through 11 on PHP 8.0 and above. Older Laravel releases map to earlier majors, including 4.x for Laravel 6 and 2.x or 3.x for Laravel 5.1 through 5.8. Version pinning is strict and the package moves in lockstep with Laravel majors, so budget a small upgrade spike whenever you move Laravel versions.
- Does Lada Cache cache raw SQL like DB::select() or queries from third-party packages?
- No. Lada Cache explicitly does not cache DB::select(), DB::statement(), or raw SQL calls, and third-party packages that use custom query builders can bypass it silently. Complex query constructs may degrade to table-level tagging or skip caching entirely. Before committing, measure what percentage of your production queries are raw SQL or issued through packages with custom builders, because realized benefit will be uneven across endpoints.
- How does cache invalidation work in Lada Cache, and is it safe with composite primary keys?
- Writes automatically invalidate only the affected rows or tables, which is what keeps hit rates high without manual cache busting. Row-level tagging assumes a single-column primary key; tables with composite or unconventional keys fall back to coarser table-level invalidation, lowering hit rates and increasing database load. Invalidation correctness is the dominant risk, and the changelog shows a history of tagging, key-collision, and deferred-mutation fixes. Test freshness-critical flows deliberately with write-then-read checks rather than assuming automated behavior is enough.
- Can I exclude specific tables or bypass the cache for freshness-critical queries?
- Yes. The configuration includes table include and exclude lists, TTL settings, and a key prefix, and you can call withoutCache() on flows that must read fresh data. A global on/off switch and an environment kill switch give you runtime control as well. This lets you keep caching off for high-stakes write-then-read paths while still caching read-heavy endpoints.
- How do I disable or flush Lada Cache in production?
- Set the LADA_CACHE_ACTIVE environment variable to disable caching without code changes, and use the packaged console commands to flush, enable, or disable the cache. Together these give you a clean rollback path if invalidation behaves unexpectedly after a deploy. Test the kill switch under realistic conditions so it works quickly during an incident.
- What are the production risks of running Lada Cache, especially if Redis goes down?
- Redis becomes a read-path dependency for cached queries, and the package does not define fallback behavior when Redis is unavailable, so how your application degrades is a design decision you must implement and test. Stale reads caused by invalidation gaps are the highest-severity failure mode because they erode user trust and are hard to detect without deliberate testing. Redis-only support also removes the option to substitute another cache backend, which makes sizing, eviction policy, cluster mode, and isolation from sessions and queues important operational concerns.
- Does Lada Cache work with read replicas, multiple connections, or multi-tenant applications?
- Multiple connections are supported only through Lada's own connection integration; read replicas, tenant connection switching, and packages that bind their own connections need explicit verification in your setup. Transactions using lockForUpdate or sharedLock are also worth testing in the target topology. Validate these cases against a staging workload that mirrors production connections before trusting hit rates or invalidation behavior.
- What performance improvement can I expect from Lada Cache, and is it worth adopting?
- The README reports gains ranging from 5% to 95%, with a typical 10 to 30 percent latency improvement and reduced database load, but treat those figures as directional only. Real benefit depends on how many repeated queries your requests issue and your cache hit rate, neither of which you know until you measure. Lada Cache fits read-heavy, repetitive Eloquent workloads that already run Redis as first-class infrastructure. Build a benchmark harness against your own workload before committing.