Prisma를 node 서비스 한 개에 본격 도입한 지 정확히 1년 됐다. 2.0 GA 직후 쓰기 시작했으니까. 지금은 2.30 정도. 매월 버전 빠르게 올라오는 중. 회고 정리.
좋았던 것
타입 생성이 진짜 강력하다. schema.prisma 한 파일이 DB 스키마와 TS 타입의 single source of truth가 된다. migration 돌리면 TS 타입이 같이 업데이트되니까 drift가 안 난다. TypeORM 쓸 때 겪던 "런타임 가서야 컬럼 이름 틀린 거 안다" 같은 문제 사라짐.
쿼리 API가 명시적. prisma.order.findMany({ where, include })처럼 인자 구조로 쓰니까 오토컴플릿 안내 보면서 짜게 됨. ORM 메서드 체이닝보다 훨씬 안정적.
마이그레이션 툴 좋음. prisma migrate dev로 스키마 변경하면 SQL까지 보여주고 확인. git으로 추적되기 때문에 리뷰하기 쉽다.
걸렸던 것 — 솔직하게
복잡한 쿼리는 힘들다. 서브쿼리, window function, recursive CTE 필요한 순간 Prisma로는 못 쓴다. $queryRaw로 빠지는데 그럼 타입 이득이 줄어듦. 우리는 조회 API 중 20% 정도는 raw sql이 됐고, 이 부분만 따로 관리하게 됨. 처음부터 "복잡한 쿼리는 raw로 간다"로 선을 그었어야 함.
connection 관리. 서버리스 환경에서 Prisma Client 인스턴스 재생성되면 커넥션 누수 쉽게 남. 이걸 모르고 AWS Lambda에 그대로 쓰다가 RDS 커넥션 상한 맞음. 글로벌 싱글턴 패턴 강제 필요. 지금은 Prisma Data Proxy라는 게 프리뷰로 나왔는데 아직 안 써봄.
N+1. include로 relation 먹는 건 편하지만, 여러 레이어 깊어지면 쿼리 수가 폭발. 2.16쯤부터 findMany + in 조합으로 최적화 들어갔지만 여전히 조심스럽게 써야 함.
migrate deploy의 롤백. 없다. 사실상 forward-only. 롤백이 필요하면 역마이그레이션 직접 짜야 함. 이건 도입 전 몰랐던 부분이라 운영 중 한 번 프로덕션에서 당황했음.
그래서 다시 선택하겠는가
Node 기반 서비스면 yes. TypeORM 대비 장점이 너무 명확하다. 단, 팀에 SQL 잘 쓰는 사람이 있어야 한다. Prisma만 안다고 복잡한 DB 설계는 못 한다. Prisma는 클라이언트일 뿐이고 DB 설계는 따로 해야 한다는 마인드로 써야 함.
뭘 해봐도 결국 ORM은 taste의 영역인 것 같다. 팀이 편한 거 쓰면 된다.
