Huge app start times when deploying Prisma to a lambda with NestJS

Bug description

With a simple NestJS application which uses Prisma as described in the recipe, app start times on Lambda are as very high as compared to NestJS applications which do not use Prisma.

Background

I have 3 standalone NestJS applications, each deployed as a lambda function behind an API Gateway. Two of the (profile and auth) use Prisma and one (hello) does not.

• The size of profile and auth is 1.5MB each as all lambdas are bundled using Webpack and they bundle the Prisma Client and all other required node-modules into a self-containing bundle
• The size of hello is around 1MB
• Size seems to be a non-issue
• @prisma/cli is not bundled. Only @prisma/client is
• The rhel-openssl-1.0.x query engine is generated locally and made available to all the lambdas via layers
• The PRISMA_QUERY_ENGINE_BINARY path is set to /opt/rhel-openssl-1.0.x as the lambda layer is extracted into /opt directory
• All lambdas have 1024MB of memory allotted to them and a 30 seconds timeout (standard for API Gateway)
• The hello function takes ~100ms to start while reading some content from /opt folder

This was initially discussed on the Slack thread this issue is to document it.

Issues

• The profile and auth functions take over 15000 - 20000ms to start as they contain Prisma
• If the lambda memory is reduced to 128MB then:
  • The hello function still starts in the same amount of time
  • The profile and auth functions timeout atleast the first two times and the API throws an error
  • On the third call the entire thing bootstraps again and then we receive a response by around the 16000ms mark

Here are the CloudWatch logs indicating the two drastically different startup times:

1. With Prisma
2. Without Prisma

Expected behavior

Prisma should not be a bottleneck while bootstrapping a lambda function as other file-read operations perform 10x faster.

Prisma information

There are no queries being made to the database so far and the Prisma schema is just the one found in the quickstart guide with an additional binaryTargets and output specified in the generator client block.

Environment & setup

• OS: AMI
• Database: Postgres
• Node.js version: 12.x
• Prisma version:

@prisma/cli          : 2.13.1
@prisma/client       : 2.13.1
Current platform     : darwin
Query Engine         : query-engine fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Studio               : 0.329.0

[janpio]

(In our release 4.8.0 we have made significant improvements, average decrease of 50%, on the size of our engine files. That should ease the pain, but we will continue looking into other solutions of course. Expect more updates from us in this direction soon.)

[sreuter]

Suffering from the same issue, 3-4 seconds cold start times on Lambda with Prisma. How can we help tracking this down and get fixed?