Caching in-memory postgraphile objects for performance.
Refer https://github.com/graphile/postgraphile/issues/693 for some context, as this seems to be an extension of the other issue and specifically this comment from @benjie in 2018:

> Are you trying to load it up as an executable schema? If so you cannot do that via JSON because the schema is generated in memory. We don't have a way for doing that currently - it's highly dynamic.

Thing that works:
1. A process generates the SDL in postgraphile using `writeCache` option and stores this Graphql SDL.
2. API call triggers the lambda, which then reads this SDK using the `readCache` option, which then handles the query and returns the response.

Problem:
Our instrumentation shows that that `createPostgraphileSchema` function takes ~2-2.5 seconds of time to read the cache file and then make the call to database to resolve the query. Our response times during has changed from 1-2 secs overall to >4 seconds now. One problem might be the size of the SDL, which on an average for us is ~2.5MB as JSON.

Question:
I try to use `createPostgraphileSchema` in the first lambda run, and then try to cache the postgraphile object (in some caching system like memcached or redis or such; memcached response times are in milliseconds) and then reload it in a subsequent lambda run. A serialisation operation of the schema and resolvers (in the first run) and a comparatively faster deserialisation of the object in memory should be much faster than reading the schema repeatedly and creating the object in memory for every Lambda API call.

Apparently, it seems to not work as thought as serialising the GraphQL schema object seems to be impossible. Is there a way the community has handled this issue when using Graphql on serverless and tuning for performance?