If you are after performance and self-cleansing then the cacheservice is the best solution for caching, and if you are after permanence and small amounts of data, the properties service is a good solution. You can also get round many of the limitations of each service using my properties and cache plugins, covered in Squeezing more into (and getting more out of) Cache services

However – what if you want

  • permanence
  • sharing across multiple projects
  • much bigger payloads

At the expense of self expiry and performance you could use my CrusherPluginDriveService

You’ll need the cUseful library


Built in plug-ins

This works exactly like the the plugins for CacheService and PropertyService, and are supported through plug-ins available from the cUseful library. Here’s how to use each of them.

Properties Service

Cache Service

Drive Service


as with cacheservice and property service 3 methods are supported. Note that although the expiry dates are respected for whether to return results, the files are not automatically pruned unless accessed as Drive doesnt support automatic expiry pruning so you may need to clean up your folder from time to time.


This can be of any type, or even an object, for example


This can be of any type, for example

Getting the item will reconstitute to its original form. A missing item will return null

An item can be removed like this, irrespective of type.

How does it work?

The main techniques are

  • If data is over a certain size, then it will be automatically compressed and uncompressed when retrieved
  • If data is still too large for a given store’s limits (which you can set), then it will create a series of linked items, which are reconstituted when retrieved.
  • Objects are stringified and re-parsed automatically when detected
  • Dates are converted to timestamps, then back again when retrieved
  • Blobs are converted to base64, preserving their content type and name, and reconverted when retrieved
  • The store is abstracted from the crusher, so the methods are exactly the same, irrespective of which underlying store is being used.


These examples for the built in property stores and cache stores show some initialization options.


You need to at least pass a store to use, and a prefix with the path to an existing Drive folder.

You can set a few other options to affect the behavior, although there’s probably not much call for these in normal usage (other than plug-in testing).

This example sets small chunk sizes (which would provoke spreading the data over multiple entries) and a small compression threshold (normally compression will actually increase the size of anything under about 200 bytes). By default anything under 250 bytes is not compressed. The default chunksize for the drive plugin is 5mb


You can write your own plug-ins to support other stores such as databases, cloud storage, even spreadsheets. Essentially – anything that can be used as a key/value store. See Squeezing more into (and getting more out of) Cache services for an example of writing a plugin to support cloud storage.

A benefit of this plugin approach is that each driver is used in exactly the same way. Here’s a test that runs 3 different plugins, yet the code is exactly the same, aside from the initialization parameters.

test results

We can also use this to compare performance – drive is a lot slower than the others, but of course is a better choice if you need permanence.

  • cache – 500ms
  • property store – 800ms
  • drive – 4500ms
For more like this see Google Apps Scripts Snippets
For help and more information join our community, follow the blog or follow me on Twitter