2026년 5월 14일1분 읽기

Bun + Prisma 5.22 콜드 스타트가 1.4초 — Node 22 대비 오히려 느려요

김

김영삼

조회 510댓글 3

"Bun이 Node보다 빠르다"는 글들 보고 Lambda로 옮겼는데 콜드 스타트가 오히려 느려졌습니다. 운영 배포 전에 확인하고 싶습니다.

환경

AWS Lambda, ARM64, 메모리 1024MB
Node 22: 콜드 920ms, 웜 22ms
Bun 2.0: 콜드 1,420ms, 웜 18ms
Prisma 5.22(공식 Bun 지원 버전)

패키지 크기는 Bun이 더 작은데, Lambda init 단계에서 1초 이상 걸립니다. Prisma query engine 초기화가 원인 같은데, 같은 경험 있으신가요?

pgvector에서 Qdrant로 마이그레이션 — 1.2억 벡터인데 다운타임 어디까지 줄일 수 있나요

Stripe Connect 한국 사업자 정산 — 매월 15일 받는데 한국 PG 대비 수수료가 얼마나 차이나나요

김김영삼5개월 전

흔한 함정입니다. "Bun이 빠르다 = HTTP 처리량이 빠르다"지 콜드 스타트가 빠르다는 보장은 없습니다. 특히 Lambda + Prisma 조합은 다음 두 가지 때문에 Bun이 손해를 봅니다.

원인 1 — Prisma query engine binary 로드

Prisma는 native binary(libquery_engine)를 로드합니다. Bun은 dlopen 경로가 Node와 미세하게 다르고, 첫 호출 시 binary signature 검증을 더 엄격히 합니다. 실측으로 Node 220ms vs Bun 480ms 차이 봤습니다.

원인 2 — Bun runtime 자체 init

Bun runtime이 Node 대비 작긴 하지만, Lambda init context에서는 V8 snapshot 이점이 큽니다. AWS는 Node에 SnapStart 비슷한 최적화를 적용했지만 Bun에는 없습니다.

해결 — accelerate 사용 또는 connection pool 분리

Prisma Accelerate 사용 — query engine을 외부로 빼서 콜드 스타트 -800ms

또는 Drizzle로 교체 — pure JS라 Bun과 친화적, 콜드 380ms로 떨어집니다

Lambda SnapStart Node 사용 — Bun 포기하고 Node + SnapStart 조합이 가장 빠름(콜드 280ms)

저는 결국 Lambda 워크로드는 Node + SnapStart로 남기고, 컨테이너 워크로드(Fargate, EC2)만 Bun으로 옮겼습니다. Lambda + Bun은 아직 production-ready가 아닙니다.

풀풀스택지훈5개월 전

Drizzle로 바꾸면 정말 콜드 스타트가 줄어듭니다. 저희 팀은 같은 워크로드에서 Prisma(1.2s) → Drizzle(320ms)로 떨어졌어요. 마이그레이션 도구는 prisma-migrate를 그대로 두고 런타임만 Drizzle로 쓰는 방법도 있습니다.

ccold_dev(guest)5개월 전

Bun + Lambda는 ARM64에서 일부 native module 호환 이슈도 있어요. 저희는 production은 Node, 로컬 개발만 Bun으로 쓰는 합리적 절충안을 채택했습니다. bun --bun으로 강제 실행할 때만 진짜 Bun runtime이 쓰여서, 의존성 호환성 디버깅이 어렵습니다.

Ctrl+Enter로 등록