The following describes some caveats you might face when deploying to different AWS platforms.
Prisma ORM is compatible with AWS RDS Proxy. However, there is no benefit in using it for connection pooling with Prisma ORM 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 Prisma Client's connection is dropped." -
Because Prisma ORM uses prepared statements for all queries, you won't see any benefit when using RDS Proxy with Prisma ORM.
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 ORM generates the Prisma Client code into
node_modules. This is typically done in the
Because Beanstalk limits the ability to write to the filesystem in the
postinstall hook, you need to create an file in the root of your project and add the following configuration:
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
This error happens because AWS Elastic Beanstalk doesn't install
devDependencies, which means that it doesn't pick up the Prisma CLI. To remedy this you can either:
- Add the
prismaCLI package to your
dependenciesinstead of the
devDependencies. (Making sure to run
npm installafterward to update the
- Or install your
devDependencieson AWS Elastic Beanstalk instances. To do this you must set the AWS Elastic Beanstalk
NPM_USE_PRODUCTIONenvironment property to false.
AWS Lambda defines an deployment package upload limit, which includes:
- All application code
- Binaries like the Prisma ORM query engine
The . 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 ORM engine binaries.
Prisma CLI downloads additional engine binaries that are not required in production. You can delete the following files and folders:
node_modules/@prisma/enginesfolder (refer to the used by the Prisma end-to-end tests)
The local engine file for your development platform from the
node_modules/.prisma/clientfolder. For example, your schema might define the following
binaryTargetsif 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:
node_modules/.prisma/client/query-engine-rhel-openssl-1.0.x, which is the engine file used by AWS Lambda
node_modules/.prisma/client/query-engine-debian-openssl-1.1.x, which is only required locally