Lambda Cold Start Time

Bug description

I want to use Prisma in my AWS serverless lambda functions. I’m using Serverless Stack and NodejsFunction for bundling (which uses esbuild).

I enable the minify option when bundling.

My problem: 7.5MB of generated prisma client code is included in my application. I already have a prisma lambda layer containing the engines, my issue is with the massive amount of minified JS code included in my lambda bundle. This is an issue because it makes my lambda functions start in about 2.5 seconds compared to about 600ms for my functions that don’t have the prisma client bundled:

No prisma:

With prisma:

Here is what a typical lambda bundle with prisma looks like:

I’m continuing to gather data to try to work out what fraction of my cold start time is prisma. See below comments for more details on that.

How to reproduce

Create a NodejsFunction with AWS CDK that imports a generated prisma client.

https://docs.aws.amazon.com/cdk/api/latest/docs/aws-lambda-nodejs-readme.html

Expected behavior

Since I’m using esbuild (and a lot of next-gen JS tooling is starting to use it) it would be helpful if the generated client used ES modules or at least ES6 import syntax. CommonJS is death for bundling.

I don’t know why the prisma clients are 7.5MB of minified JS. That seems highly strange. My schema file is about 800 lines. My dmmfString is 6,492,708 characters long it seems.

☝🏻 CommonJS.

https://esbuild.github.io/api/#tree-shaking

This way esbuild will only bundle the parts of your libraries that you actually use, which can sometimes be a substantial size savings. Note that esbuild’s tree shaking implementation relies on the use of ECMAScript module import and export statements. It does not work with CommonJS modules. Many libraries on npm include both formats and esbuild tries to pick the format that works with tree shaking by default.

Prisma information

3.6.0

Environment & setup

• OS: linux- lambda
• Database: postgres, aurora serverless
• Node.js version: 14

Prisma Version

prisma                  : 3.6.0
@prisma/client          : 3.6.0
Current platform        : darwin
Query Engine (Node-API) : libquery-engine dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : dc520b92b1ebb2d28dc3161f9f82e875bd35d727
Studio                  : 0.440.0

[revmischa]

Continuing to profile prisma during nodejs startup. According to this profile, 62% of my ~1.5s startup time is initializing the prisma library, with significant time spent on “findSync”

[renchap]

Can you split that information out into its own (cross-linked) issue @renchap? That would indeed be super useful for us. Thanks!

Here it is: https://github.com/prisma/prisma/issues/12132