This is the the driver for DB.SCRATCH described in Database abstraction with google apps script

The library reference is:


Background to implementation.

Note that this technique relies on the predictability of CacheService. Google warn that it’s not necessarily predictable, so at this point I’m not sure how robust this approach is, but I have many people out there using this now and haven’t had any issues reported. Having said that, its use is intended for testing, logging and so on in preparation for and in advance of moving to a more permanent back end

This driver uses cache to provide transient database storage. By default it lives for 1 hour, but its lifetime is extended each time it is accessed. It is ideal for early testing in preparation for other backends or passing data back and forwards between co-operating processes. It can handle much more data than the Properties service, and can be protected using cache communities. 


There is no authentication required, since it uses cache – normal auth will apply. However here are some tips for using this database for collaboration. You need to invent your own codes to name database elements so may as well start with a plan.

  • siloid – use a consistent key to refer to a particular set of data. This would be roughly equivalent to an application key in some of the other databases. 
  • dbid – use this to refer to the owner of a dataset. This could be equivalent to an api key.
  • scratchexpiry – by default this is 1 hour. The maximum is 6 hours. Note that a database lifetime will be extended each time you access it, so as long as you are using it, it will persist.
  • private – by default it uses the library cache restricted to the current user. This means that all your scripts, running as you, using the same library will be able to access the data if you know the siloid and dbid. If you want to extend this to be able to be accessible by other users, then set private to false. This means that anyone who can access the library and knows the siloid and dbid can access the data
  • specificcache – if you do not want to use the library cache (private or public) you can pass another cache object through this parameter – for example “specificcache”: CacheService.getUserCache()   would use the cache from your script rather than the library.
  • cachecommunity – whichever cache you are using can be further restricted by specifying a cache community. This is some code that you share between collaborators who would want to work on a particular set of data.  All of the siloid, dbid and cache community as well as access to the selected library and cache are needed to be able to access the data.

Locking and caching

Transactions, Locking and rollback are all supported by this driver.  In addition, results are cached just like any other driver. In this case, the mechanism which prolongs lifetime will not be invoked.

The code

for help and more information, join our forum, follow the blog and or follow me on Twitter