Caveats when deploying to AWS platforms

The following describes some caveats you might face when deploying to different AWS platforms.


Prisma is compatible with AWS RDS Proxy. However, there is no benefit in using it for connection pooling with Prisma due to the way RDS Proxy pins connections:

"Your connections to the proxy can enter a state known as pinning. When a connection is pinned, each later transaction uses the same underlying database connection until the session ends. Other client connections also can't reuse that database connection until the session ends. The session ends when the client connection is dropped." - AWS RDS Proxy Docs

Prepared statements (of any size) or query statements greater than 16 KB cause RDS Proxy to pin the session. Because Prisma uses prepared statements for all queries, you won't see any benefit when using RDS Proxy with Prisma.

AWS Elastic Beanstalk

AWS Elastic Beanstalk is a PaaS-like deployment service that abstracts away infrastructure and allows you to deploy applications to AWS quickly.

When deploying an app using Prisma Client to AWS Elastic Beanstalk, Prisma generates the Prisma Client code into node_modules. This is typically done in the postinstall hook.

Because Beanstalk limits the ability to write to the filesystem in the postinstall hook, you need to create an .npmrc file in the root of your project and add the following configuration:


Enabling unsafe-perm forces npm to run as root, avoiding the filesystem access problem, thereby allowing the prisma generate command in the postinstall hook to generate code into node_modules.

AWS Lambda upload limit

AWS Lambda defines an deployment package upload limit, which includes:

The deployment package (.zip) size limit for lambdas is 50MB. When you prepare a deployment package, remove any files that the function does not require in production to keep the final .zip as small as possible. This includes some Prisma engine binaries.

Deleting Prisma engine binaries that are not required

Prisma downloads additional engine binaries that are not required in production. You can delete the following files and folders:

  1. The entire node_modules/@prisma/engines folder (refer to the sample bash script used by the Prisma end-to-end tests)

  2. The native engine binary from the node_modules/.prisma/client. For example, your schema might define the following binaryTargets if you develop on Debian (native) but deploy to AWS Lambda (rhel-openssl-1.0.x):

    binaryTargets = ["native", "rhel-openssl-1.0.x"]

    In this scenario:

    • Keep node_modules/.prisma/client/query-engine-rhel-openssl-1.0.x, which is the binary used by AWS Lambda
    • Delete node_modules/.prisma/client/query-engine-debian-openssl-1.1.x, which is only required locally
Edit this page on GitHub