Kysely vs Sequelize
어떤 ORM을 쓸까?
기본
| Kysely | Sequelize | |
|---|---|---|
| 주간 다운로드 | 1254만 | 294만 |
| 최근 릴리스 | 오늘 | 155일 전 |
| 유지보수 | 🟢 활발 | 🟡 둔화 |
| 열린 이슈 | 171 | 1,075 |
유지보수 상태는 최근 릴리스 간격만으로 판정합니다 (90일 이내 🟢 · 270일 이내 🟡 · 그 이상 🔴).
쓰다 보면 만나는 것
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 · 미해결
Sequelize
- 거슬림
findAndCountAll에 include를 섞으면 count가 부풀려져 페이지네이션이 깨진다
include(JOIN)가 있으면 부모 행이 아니라 조인된 행을 세기 때문에 count가 실제보다 커진다. count: 72에 rows: 38 같은 결과가 나와 페이지네이션 계산이 어긋난다. distinct: true 옵션이나 count·find 쿼리 분리로 우회한다. 2018년부터 같은 계열 이슈가 반복 보고돼 왔다.
2025-07 · 미해결
이럴 땐 이걸
- SQL을 직접 설계하고 타입만 얹고 싶을 때 → Kysely