SQLite 프로덕션 환경: Julia Evans가 실제 운영에서 배운 것들

줄리아 에반스가 SQLite에 대한 노트를 공개했습니다: 특별할 건 없지만, 이 작은 파일에 진짜 애플리케이션을 구동하는 데 주저하는 이들에게는 매우 유용한 내용입니다.

실제 사례

Julia Evans - 리눅스, HTTP, DNS 내부 구조에 대한 зines와 글들을 통해 한 세대의 개발자들을 교육해 온 인물 -는 2026년 7월 17일 자신의 블로그 jvns.ca에 「Learning a few things about running SQLite」라는 제목의 글을 게시했습니다. 이는 SQLite에 대한 소개 튜토리얼도, 종교적 선전도 아닙니다. Julia가 자신의 서비스를 위해 SQLite를 프로덕션 환경에 직접 적용하며 느낀 놀라움을 기록한 현장 노트입니다. 정말 재미있는 글입니다.

배울 점

기사를 스포일러하지는 않겠습니다. 짧지만 영어로 작성된 글이니 직접 읽어보시기 바랍니다. 하지만 SQLite를 프로덕션 환경에서 사용할 때의 논쟁에서 자주 언급되는 몇 가지 포인트가 있어, 호기심 있는 분들을 위해 정리해 보았습니다.

1. WAL 모드: 동시성에서 필수

기본적으로 SQLite는 DELETE 저널 모드를 사용합니다. 이 경우 쓰기 작업이 읽기 작업을 차단합니다. WAL(Write-Ahead Logging) 모드에서는 읽기와 쓰기가 서로를 차단하지 않습니다.

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL(기본 FULL 대신)은 갑작스러운 전원 차단 시 최대 마지막 트랜잭션까지만 손실을 감수하는 대신, 성능을 크게 향상시킵니다. Litestream과 대부분의 현대 SQLite 서버에서 이 방식을 사용합니다.

2. 단일 쓰기 연결, 다중 읽기 연결

PostgreSQL과는 달리 SQLite는 쓰기 작업을 병렬화하지 않습니다. Rust나 Go에서 흔히 사용하는 패턴: 쓰기 전용 연결 하나, 읽기 전용 연결 풀. Rust의 rusqlite 크레이트와 deadpool-sqlite를 결합해 분리하는 방식이나, Go의 mattn/go-sqlite3 라이브러리에서 sql.DB를 SetMaxOpenConns(1)로 설정해 쓰기 전용으로 사용하는 방식 등이 있습니다.

3. 라이브 백업: Litestream 또는 LiteFS

진행 중인 트랜잭션이 있는 상태에서 SQLite 파일을 단순히 복사하는 것은 손상된 백업을 만드는 가장 좋은 방법입니다. 두 가지 도구가 주목받고 있습니다.

• Litestream (BoltDB의 저자 Ben Johnson 제작): S3, Backblaze B2, GCS 등으로 지속적인 복제. WAL 스트리밍, 빠른 복구.
• LiteFS (같은 저자, 현재 Fly.io 소속): 다중 노드 복제 지원. 어떤 복제본에서도 읽기 가능.

4. 2026년 기준 SQLite의 진정한 한계

SQLite는 WAL 모드에서 잘 인덱싱된 상태라면 단일 파일로 초당 수만 건의 쿼리를 문제없이 처리합니다. 진정한 한계는 SQL이 아니라 디스크 성능입니다: NVMe 로컬 >> 네트워크 디스크, EBS gp3 >> EFS. 많은 SQLite 프로덕션 실패 사례는 파일을 네트워크 공유(특히 NFS - SQLite 공식 문서에서 굵은 글씨로 명시적으로 금지)에 올려놓은 경우입니다.

기억할 점

Julia Evans의 관점은 언제나 「시도하고, 측정하고, findings를 기록하라」입니다. 「SQLite는 확장된다」나 「진짜 일을 하려면 PostgreSQL이 필요하다」 같은 주장은 없습니다. 그저 「이 동작이 나를 놀라게 했다, 이유는 이렇고, 나는 이걸 바꿨다」라는 식입니다.

단일 서버 애플리케이션이나 사이드 프로젝트를 위해 무거운 관계형 데이터베이스를 꺼리는 모든 개발자에게, 이런 종류의 글은 synthetic 벤치마크 백 개보다 가치가 있습니다.