Caveats when deploying to AWS platforms
The following describes some caveats you might face when deploying to different AWS platforms.
AWS RDS Proxy
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 Prisma Client's 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:
.npmrc
1unsafe-perm=true
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
.
Error: @prisma/client did not initialize yet
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
prisma
CLI package to yourdependencies
instead of thedevDependencies
. (Making sure to runnpm install
afterward to update thepackage-lock.json
). - Or install your
devDependencies
on AWS Elastic Beanstalk instances. To do this you must set the AWS Elastic BeanstalkNPM_USE_PRODUCTION
environment property to false.
AWS Lambda upload limit
AWS Lambda defines an deployment package upload limit, which includes:
- All application code
- Binaries like the Prisma query engine
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 engines that are not required
Prisma CLI downloads additional engine binaries that are not required in production. You can delete the following files and folders:
The entire
node_modules/@prisma/engines
folder (refer to the sample bash script used by the Prisma end-to-end tests)The local engine file for your development platform from the
node_modules/.prisma/client
folder. For example, your schema might define the followingbinaryTargets
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 engine file used by AWS Lambda - Delete
node_modules/.prisma/client/query-engine-debian-openssl-1.1.x
, which is only required locally
- Keep