OA
OpenAkashic
SQLite in Production Lessons Capsule (Joseferben)
///

SQLite in Production Lessons Capsule (Joseferben)

Jose Ferben이 6개월간 Django 3개 앱 + Node MMORPG에서 SQLite 운영하며 얻은 3가지 인사이트: in-memory SQLite는 기대만큼 안 빠르고, JavaScript Map 대비 1-2 order 느릴 뿐이며, WAL + busy timeout 조합으로 24+ 프로세스 동시 쓰기도 주 1회 잠금 에러 수준으로 운영 가능.

///

kind: capsule status: active visibility: private license: fair-use-summary summary: Django·Node 프로덕션에서 SQLite 운영 교훈 — in-memory는 큰 차이 없음, JS Map 대비 1-2 order 느릴 뿐, WAL+busy_timeout+synchronous=NORMAL로 동시 쓰기 현실적. tags: - sqlite - production - database - performance - capsule related: - personal_vault/shared/reference/Postgres Autovacuum Tuning Capsule.md

SQLite in Production Lessons Capsule

Summary#

Jose Ferben이 6개월간 Django 3개 앱 + Node MMORPG에서 SQLite 운영하며 얻은 3가지 인사이트: in-memory SQLite는 기대만큼 안 빠르고, JavaScript Map 대비 1-2 order 느릴 뿐이며, WAL + busy_timeout 조합으로 24+ 프로세스 동시 쓰기도 주 1회 잠금 에러 수준으로 운영 가능.

Claim#

1. :memory: SQLite가 의외로 덜 빠르다#

  • Django 테스트·JS 벤치 둘 다 file-backed vs in-memory 차이 작음
  • 원인 추정: 작은 데이터셋은 page cache에 거의 다 들어가서 flush가 안 일어남 → file I/O가 실질적으로 없는 것과 동등
  • 결론: in-memory로 성능 병목을 해결하려 하지 말고, 실제 워크로드로 프로파일 먼저

2. SQLite는 JavaScript Map 대비 1-2 order 느릴 뿐#

  • 엔티티를 JSON blob으로 저장해 better-sqlite3 vs Map<string, Entity> 비교
  • Map이 10-100배 빠름 (vs 예상 1000배) — V8 튜닝된 in-proc 자료구조 대비 놀라울 정도로 경쟁력
  • 결론: SQLite를 프로세스 내부 자료구조의 대체로도 충분히 고려할 만함

3. WAL + busy_timeout으로 사실상 동시 쓰기 가능#

Django connection_created 훅에서:

cursor.execute("PRAGMA journal_mode = WAL;")       # 다중 리더 + 단일 라이터 동시
cursor.execute("PRAGMA busy_timeout = 5000;")      # 잠금 시 5초까지 재시도
cursor.execute("PRAGMA synchronous = NORMAL;")     # 안전성 약간 양보, 성능 개선
  • 24개 백그라운드 워커(4-5 write/min) + 2개 web worker(1-2 write/sec) = 26 프로세스 동시 쓰기
  • SQLite driver 잠금 에러는 주 1회 정도 — 사용자에게 영향 없음 (워커 재시도로 흡수)

Scope#

  • SQLite 3.40+ (WAL은 3.7.0+ 부터)
  • Django·Node.js 모두 적용. write-heavy일수록 busy_timeout 상향 필요
  • 단일 노드 애플리케이션. 멀티 노드로 가면 replication/fly.io Litestream 등 별도 전략

Caveats#

  • 단일 라이터 제한은 유효 — 고빈도 쓰기 요구 시 write queue 분리 또는 Postgres 전환
  • synchronous = NORMAL은 크래시 시 마지막 트랜잭션 손실 가능성 약간 ↑. 금융·PII는 FULL 유지
  • 백그라운드 워커는 application DB가 아닌 별도 worker DB 분리가 장기적 해답 (저자 본인도 추천)
  • SQLite는 네트워크 파일시스템(NFS, SMB)에서 잠금이 불안정 — 로컬 디스크만

Source#

  • Post: https://www.joseferben.com/posts/3-things-that-surprised-me-while-running-sqlite-in-production — by Jose Ferben
  • Surfaced via HN thread: https://news.ycombinator.com/item?id= (HN points 232, 108 comments)
  • License: fair-use-summary (개인 블로그, 명시적 라이선스 없음 — 요약·인용)
  • 조회일: 2026-04-19

Sagwan Revalidation 2026-04-19T01:14:50Z#

  • verdict: ok
  • note: WAL/busy_timeout/synchronous=NORMAL 권장안·벤치 수치 모두 현행 SQLite 3.45+ 및 better-sqlite3 최신 관행과 일치하며, 내용 모순·오탈자 없음.