SQLite가 프로덕션으로 돌아왔다 — Litestream·Turso·LiteFS 실전 비교

핵심 요약

전통적으로 SQLite는 단일 프로세스·단일 파일 DB였다. 2023년 이후 복제·동기화·에지 분산을 제공하는 레이어들이 등장하면서 상황이 달라졌다.

• Litestream: S3로 스트리밍 백업 (단일 쓰기 노드)
• Turso: libSQL 포크 + 에지 복제 매니지드 서비스
• LiteFS: Fly.io의 FUSE 기반 분산 SQLite

SQLite가 다시 매력적인 이유

• 지연시간: 디스크에 파일이 있으니 네트워크 RTT 0ms
• 운영 단순화: 별도 DB 서버·풀·네트워크 정책 불필요
• 가격: Postgres 관리형 대비 10~100배 저렴
• 성능: 단일 노드 100k+ 읽기 TPS, 쓰기도 10k+ (WAL 모드)

Litestream — 가장 단순, 가장 확실

아키텍처

SQLite WAL을 실시간으로 S3·GCS에 스트리밍. 9초마다 체크포인트. 장애 시 몇 초 전 상태로 복구.

적합한 경우

• 단일 서버·단일 쓰기 노드로 충분한 워크로드
• RDS 백업 없이 저가 복구 전략이 필요할 때
• 관리자 페이지·내부 도구·블로그

설정

# litestream.yml
dbs:
  - path: /data/app.db
    replicas:
      - type: s3
        bucket: my-backup
        path: app
        region: ap-northeast-2

한계

복수 라이터 불가. 리더가 많아도 쓰기는 한 곳. Fly.io가 2023년 회사를 인수해 유지보수 모드로 전환된 점은 주의.

Turso — 매니지드 + 에지 복제

아키텍처

libSQL(SQLite 포크) 기반의 매니지드 서비스. 전 세계 수십 개 리전에 읽기 복제본, 쓰기는 primary 한 곳.

적합한 경우

• 글로벌 서비스의 에지 읽기 최적화
• Supabase·Neon 대비 저렴한 대안 탐색
• 멀티 테넌트 SaaS (테넌트별 DB 쉽게 생성)

특징

• Edge replication: 서울 사용자는 서울에서 읽기
• HTTP API + 공식 드라이버 (TS/Go/Rust 등)
• branching(브랜치별 DB 복사) 지원 — PR 미리보기 용이

한계

• 쓰기 지연: primary 리전 바깥에서는 네트워크 RTT 누적
• 매니지드 비용이 규모 커지면 Postgres와 격차 축소
• 순수 SQLite 호환성에서 이탈하는 부분 존재(libSQL 확장)

LiteFS — 진짜 분산 SQLite

아키텍처

FUSE 기반으로 SQLite 파일을 여러 노드에 복제. 한 노드가 primary, 나머지는 팔로워. 앱 코드 수정 없이 여러 리전에 분산 가능.

적합한 경우

• Fly.io 같은 엣지 플랫폼 전제 배포
• "DB를 데이터센터에 가깝게 두고 싶다"는 요구
• 단일 라이터 + 다수 리더 구조 OK

한계

• FUSE 의존 → 마운트·권한 이슈 가능
• 쓰기 페일오버 시 일부 트랜잭션 유실 가능 (리더 재선출)
• Fly.io 의존도 높음

선택 가이드

실전 주의사항

• WAL 모드 필수 — journal_mode=WAL, 동시 읽기 확보
• PRAGMA synchronous=NORMAL — WAL 모드에서 안전·성능 균형
• 백업은 파일 복사 금지. VACUUM INTO 또는 복제 레이어 사용
• 마이그레이션은 Alembic/Drizzle/Prisma 정식 지원 활용

자주 묻는 질문

수천 명 동시 접속도 견디나?

읽기는 전혀 문제없다. 쓰기는 단일 라이터 특성상 수백 TPS가 현실적 상한. 그 이상이면 Postgres가 맞다.

Postgres에서 SQLite로 돌아오는 게 맞나?

워크로드가 과거 가정보다 가볍다는 걸 확인한 경우만. 단순 CRUD·관리자 페이지·블로그에는 맞고, 복잡 트랜잭션·동시성 쓰기에는 여전히 Postgres가 정답.

Cloudflare D1과는?

D1도 SQLite 기반. Cloudflare Workers와 찰떡이지만 현재 크기·쿼리 제한이 있다. 잠금·특수 쿼리 요구가 크면 Turso가 더 유연하다.