Drizzle ORM vs Kysely
어떤 ORM을 쓸까?
기본
| Drizzle ORM | Kysely | |
|---|---|---|
| 주간 다운로드 | 1817만 | 1254만 |
| 최근 릴리스 | 43일 전 | 오늘 |
| 유지보수 | 🟢 활발 | 🟢 활발 |
| 열린 이슈 | 1,945 | 171 |
유지보수 상태는 최근 릴리스 간격만으로 판정합니다 (90일 이내 🟢 · 270일 이내 🟡 · 그 이상 🔴).
쓰다 보면 만나는 것
Drizzle ORM
- 거슬림
down 마이그레이션이 없어 롤백은 손으로 역방향 SQL을 쓰는 일이 된다
drizzle-kit은 up 방향 마이그레이션만 생성한다. 배포 후 스키마를 되돌리려면 역방향 SQL을 직접 작성해야 하며, 순차 번호 방식이라 여러 명이 동시에 마이그레이션을 만들면 머지 충돌이 난다. 롤백 기능 요청은 2024년부터 priority 라벨로 열려 있다.
2025-05 · 미해결
- 거슬림
서버리스·HTTP 계열 드라이버에서는 인터랙티브 트랜잭션이 제한되거나 지원되지 않는다
Cloudflare D1 드라이버는 트랜잭션을 지원하지 않고, Neon HTTP 드라이버도 인터랙티브 트랜잭션을 잡을 수 없어 우회 설계(멱등키 등)가 필요하다. sqlite 계열도 5개 구현 중 4개가 async 트랜잭션 콜백을 지원하지 않는다. 엣지 배포가 세일즈 포인트인 만큼 뒤늦게 발견하면 아프다. TCP 드라이버(pg, postgres.js)에서는 트랜잭션이 정상 동작함을 2026-08에 직접 확인했다.
2026-03 · 미해결
- 사소
tx.rollback()은 예외를 던지는 API라서 호출자까지 에러가 전파된다
수동 롤백 시 롤백 자체는 정상 수행되지만 DrizzleError: Rollback이 transaction() 밖으로 던져진다. 문서에 한 줄 언급이 있으나, 다른 ORM에서 온 사용자가 이를 버그로 오인한 보고가 이어져 왔다. 정상 흐름으로 쓰려면 호출부에서 잡아야 한다. drizzle-orm 0.45.2에서 3개 드라이버로 직접 재현·확인했다.
2026-08 · 미해결
Kysely
- 거슬림
테이블 타입을 손으로 쓰거나 서드파티 codegen에 의존해야 한다
Kysely는 스키마 정의가 없다. Database 인터페이스를 Generated·ColumnType 래퍼로 직접 작성하는 것이 기본이고, 공식 문서도 프로덕션에서는 DB 인트로스펙션으로 타입을 생성하라고 안내한다. 그 생성 도구(kysely-codegen 등)는 본체가 아닌 커뮤니티 프로젝트다. 타입의 출처가 코드가 아니라 외부 도구라는 점을 설계에 넣어야 한다.
2026-08 · 미해결
- 거슬림
복잡한 쿼리에서 빌더·타입 추상화의 한계에 부딪힌다
단순 CRUD는 매끄럽지만, SQL 술어를 빌더 표현으로 옮기는 방법을 문서에서 뒤져야 하는 경우가 생기고, 조인 비교나 selectAll 등에서 타입이 실제 결과와 어긋나는 열린 버그들이 있다. relations·eager loading이 없어 중첩 객체는 손으로 조립한다.
2026-02 · 미해결
- 거슬림
마이그레이션 자동 생성과 스키마 diff가 없어 up/down을 손으로 쓴다
마이그레이션은 up·down 함수를 직접 작성하는 방식이며, 스키마 정의에서 diff를 떠서 생성해주는 도구가 본체에 없다. prisma migrate나 drizzle-kit 같은 자동 생성에 익숙하면 워크플로를 다시 설계해야 한다. 반대로 이 명시성이 장점이라는 시각도 있다 — 손으로 쓴 up/down은 롤백 경로가 항상 존재한다.
2026-08 · 미해결
이럴 땐 이걸
- 엣지·서버리스 배포 (트랜잭션 제약은 확인할 것) → Drizzle ORM
- SQL을 직접 설계하고 타입만 얹고 싶을 때 → Kysely