Tiago Ferreira

measure before you migrate. the lambda REPORT log line has an Init Duration field on cold starts, that's the part you can actually attack. in my experience on node it splits into: loading the bundle, initialising clients at module scope, and whatever your ORM does on startup. prisma's engine is often the biggest single chunk, so check that first. cheap things to try before spending money: - switch the functions to arm64. usually a bit faster to init and cheaper per ms - lazy-load anything heavy that only some routes need - make sure you're on the modular v3 AWS SDK and only importing the clients you use on workers: the compute moves to the edge, your database doesn't. a user in são paulo hits a worker in são paulo, which then makes a round trip to virginia for every query. edge compute in front of a single-region database is a very fast way to wait for the database. you'd also need connection pooling (hyperdrive or a driver that works there) and prisma's driver adapters. it's doable, it's just not free, and it doesn't fix the latency you think it fixes. if init is still bad after trimming: provisioned concurrency on the 2-3 latency-critical functions only, and schedule it for business hours with application auto scaling instead of 24/7. that changes the conversation with finance a lot.