A Redis based, automated and scalable database caching layer for Laravel 5.1+
Latest commit 4610fe6 Dec 28, 2016 @spiritix committed on GitHub Update README.md


Lada Cache

A Redis based, automated and scalable database caching layer for Laravel 5.1+

Build Status Code Climate Total Downloads Latest Stable Version Latest Unstable Version License


  • Automatically caches all database queries
  • Intelligent cache invalidation with high granularity
  • Works with existing code, no changes required after setup
  • Possibility to cache only specific models or exclude some models
  • Makes use of Laravel Redis (supports clustering)
  • Supports PHP7


The performance gain achieved by using Lada Cache varies between 5% and 95%. This heavily depends on the quantity and complexity of your queries. The more queries per request your application fires and the more complex they are, the bigger the performance gain will be. Another important factor to consider is the amount of data returned by your queries, if a query returns 500MB of data, Lada Cache won't make it faster at all. Based on experience, the performance gain in a typical Laravel web application is around 10-30%.

Other than the performance gain, an essential reason to use Lada Cache is the reduced load on the database servers. Depending on your infrastructure, this may result in reasonable lower cost and introduce new possibilities to scale your application.


Most RDBMS provide internal caching systems (for example Mysql Query Cache). Unfortunately, these caching systems have some very serious limitations:

  • They do not cache queries over multiple tables (especially joins)
  • The invalidation granularity is very low
  • They are not distributed, if you have multiple database servers the cache will be created on all of them
  • They are not scalable

This library offers a solution for all of these problems.

Why only Redis?

As you may have discovered while looking at the source code, this library is built directly on top of Laravel Redis and not Laravel Cache which would make more sense from a general point of view. However, there are several important reasons behind this decision:

  • Storage must be in-memory (wouldn't make much sense otherwise)
  • Storage must be easily scalable (have fun with Memcached)
  • Storage must support tags (Laravel Cache does support tags, but the implementation is very bad and results in a massive overhead)

If you still want to use another storage backend, please feel free to contribute.



Lada Cache can be installed via Composer by requiring the spiritix/lada-cache package in your project's composer.json.

php composer.phar require spiritix/lada-cache

Now you must register the service provider when bootstrapping your Laravel application. Find the providers key in your config/app.php and register the Lada Cache Service Provider.

    'providers' => array(
        // ...

Finally, all your models must extend the Spiritix\LadaCache\Database\Model class. It's a good practice to create a base model class which extends the Lada Cache model and then gets extended by all your models.

class Post extends Spiritix\LadaCache\Database\Model {

Don't try to only have specific models extending the Lada Cache model, it will result in unexpected behavior. In the configuration, you will find the possibility to include or exclude specific models.


Use the following command to publish the lada-cache.phpconfig file to your configuration folder:

php artisan vendor:publish

Console commands

You may truncate the cache by running the following command:

php artisan lada-cache:flush

If you want to temporarily disable the cache (for example before running migrations), use these commands:

php artisan lada-cache:disable
php artisan lada-cache:enable

Known issues and limitations

  • Does not work with raw SQL queries. This would require an SQL parser to be implemented which is quite hard and very inefficient. As long as you are only using raw queries for reading data, it just won't get cached. Serious issues will only occur if you use raw queries for writing data (which you shouldn't be doing anyway).
  • Invalidation on row level does only work if you use id as column name for your primary keys.
  • The cache must be truncated manually after migrations are executed.


Contributions in any form are welcome. Please consider the following guidelines before submitting pull requests:

  • Coding standard - It's mostly PSR-2 with some differences.
  • Add tests! - Your PR won't be accepted if it doesn't have tests.
  • Create feature branches - I won't pull from your master branch.


Lada Cache is free software distributed under the terms of the MIT license.