SQLite 언제 써야 할까? 사용 사례와 한계 정리

핵심 질문부터 짚고 가기

SQLite는 Postgres의 축소판이 아니다. 애초에 결이 다른 도구다. 데이터베이스 전체가 디스크 위의 파일 하나로 존재하고, 애플리케이션은 같은 프로세스에 링크된 라이브러리를 통해 그 파일과 직접 대화한다. 서버도 없고, 네트워크도 없고, 사용자 계정도 없다. 이런 설계 덕분에 SQLite는 어떤 작업에는 압도적으로 잘 맞고, 어떤 작업에는 영 어울리지 않는다.

그래서 SQLite를 언제 사용할지 판단할 때 던져야 할 질문은 보통 "SQLite가 충분히 빠른가?"가 아니다(대부분의 경우 빠르다). 진짜 질문은 "내 애플리케이션의 _모양_이 SQLite가 잘하는 일과 맞아떨어지는가?"이다. 이걸 결정짓는 요소는 크게 두 가지다. 데이터가 어디에 사는지, 그리고 동시에 쓰기를 시도하는 주체가 몇 개인지.

데이터가 앱과 함께 사는 경우라면 SQLite

SQLite가 가장 빛나는 순간은 데이터베이스가 한 머신 위의 한 애플리케이션에 속해 있을 때다. 파일은 코드 바로 옆에 놓이고, 앱은 그 파일을 직접 열어서 쓴다. 이게 아키텍처의 전부다.

-- 전형적인 "데이터가 앱과 함께 사는" 스키마:
-- 데스크톱 노트 앱의 로컬 저장소.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('장보기', '우유, 빵, 커피'),
    ('아이디어',     'sqlite 튜토리얼 개요');

SELECT id, title, created FROM notes;

위에 보여드린 작은 스키마 하나로 실제 앱의 백엔드 전체를 굴릴 수도 있습니다. 이런 패턴이 자연스럽게 어울리는 몇 가지 경우를 살펴보겠습니다.

• 데스크톱·모바일 앱. 구조화된 로컬 저장소가 필요한 iOS, 안드로이드 앱은 거의 모두 내부적으로 SQLite를 씁니다. Firefox, Chrome을 비롯한 대부분의 브라우저도 마찬가지죠.
• CLI 도구. git, 패키지 매니저, dotfile 관리 도구 같은 것들도 임베디드 DB로 SQLite를 활용합니다.
• 임베디드 장치. 공유기, 자동차, 비행기 — 수백 킬로바이트 안에 데이터베이스를 욱여넣어야 하는 환경이라면 SQLite만 한 게 없습니다.
• 테스트 스위트. 테스트마다 새 SQLite 파일(또는 :memory: 데이터베이스)을 띄우는 방식이 Postgres를 매번 기동하는 것보다 훨씬 빠르고 격리도 잘 됩니다.

데이터를 여러 머신이 공유할 필요가 없다면, 정답은 거의 항상 SQLite입니다.

읽기 위주 웹사이트라면 SQLite

SQLite는 읽기 작업에 정말 강합니다. 동시 읽기 요청이 아무리 많아도 경합이 거의 없고, 인덱스가 걸린 조회는 마이크로초 단위로 끝납니다. 블로그, 문서 사이트, 마케팅 페이지, 소규모 SaaS 대시보드처럼 사용자가 주로 콘텐츠를 읽기만 하는 서비스라면 SQLite로도 충분히 버팁니다. 오히려 네트워크 너머에 있는 Postgres보다 빠를 때가 많은데, 왕복 통신이 아예 없기 때문이죠.

-- 블로그의 게시물 테이블.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', '안녕, 세계', '첫 번째 게시물.', '2024-01-01'),
    ('sqlite-rocks', 'SQLite를 사용하는 이유',  '단일 파일 DB.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

문제는 쓰기 작업입니다. SQLite는 쓰기를 직렬화하기 때문에 락을 잡을 수 있는 작성자는 한 번에 단 하나뿐입니다. 작성자가 몇 명뿐인 블로그라면 이런 제약은 거의 느껴지지 않지만, 초당 수천 명이 메시지를 쏟아내는 채팅 앱이라면 얘기가 달라집니다.

WAL 모드(write-ahead logging, 뒤에서 다룹니다)를 켜면 읽기와 쓰기가 병렬로 진행될 수 있어 처리 한계가 크게 올라갑니다. 실제로 SQLite + WAL 조합으로 하루 수백만 건의 요청을 처리하는 프로덕션 서비스도 많습니다.

로컬 캐시와 임시 데이터 저장용으로 SQLite 활용하기

JSON 파일로는 부족하지만 그렇다고 본격적인 DB 서버까지는 필요 없는 상황, 즉 구조화된 로컬 저장소가 필요할 때 SQLite만큼 쓸 만한 선택지는 드뭅니다.

-- HTTP 클라이언트를 위한 캐시 테이블입니다.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

로그, 분석 버퍼, ETL 스테이징, 머신러닝 피처 스토어, IDE 인덱스 — 모두 SQLite가 자연스럽게 어울리는 영역입니다. 파일 하나로 이동이 자유롭고, 질의 언어는 풀 SQL을 지원하며, 따로 관리해야 할 서버도 없습니다.

동시 쓰기가 많다면 SQLite는 피하세요

이 부분이 SQLite의 가장 큰 한계이자, 많은 분들이 뒤늦게 깨닫는 지점입니다. SQLite는 데이터베이스 단위의 쓰기 락을 사용합니다. 즉, 한 번에 단 하나의 쓰기 작업만 허용됩니다. 두 프로세스가 동시에 INSERT를 시도하면 한쪽은 무조건 대기해야 합니다.

대부분의 앱에서는 큰 문제가 되지 않습니다. 쓰기 자체가 드물고 빠르게 끝나기 때문이죠. 하지만 다음과 같은 워크로드라면 이야기가 달라집니다.

• 수천 명의 사용자가 동시에 쓰기를 일으키는 멀티테넌트 SaaS
• 처리량이 높은 메시지 큐나 이벤트 로그
• 상태 변경이 끊임없이 일어나는 실시간 게임이나 채팅 백엔드

이런 경우 SQLite는 곧바로 병목이 됩니다. PostgreSQL과 MySQL은 로우 단위 락(row-level locking)을 사용하며, 애초에 이런 시나리오를 위해 설계되었습니다. 이런 워크로드라면 주저하지 말고 그쪽을 선택하세요.

-- ライターが重なったときに表示されるエラー:
Error: database is locked

일반적인 부하 상황에서 이런 증상이 보인다면, SQLite가 잘못된 선택인 겁니다. 우회해야 할 버그가 아니라요.

여러 대의 서버에서 SQLite를 쓰지 마세요

SQLite는 애플리케이션 프로세스 안에서 동작하는 라이브러리입니다. 애플리케이션이 파일을 직접 읽고 쓰기 때문에, 그 파일은 일반 파일시스템 호출인 read()와 write()로 접근할 수 있는 디스크 위에 있어야 합니다.

그래서 다음 같은 구성에는 적합하지 않습니다:

• 로드 밸런서 뒤에서 여러 애플리케이션 서버가 하나의 DB를 공유하려는 경우. (NFS 같은 네트워크 파일시스템에서도 이론상 동작하긴 하지만, 부하가 걸리면 파일이 손상됩니다. 절대 하지 마세요.)
• 서버리스 함수처럼 호출마다 다른 머신에서 실행되는 환경.
• 쿠버네티스 파드에서 DB를 공유해야 할 때 — 단일 파드 + 퍼시스턴트 볼륨 구성이 아니라면 곤란합니다.

여러 머신의 여러 프로세스가 같은 DB에 쓰기를 해야 하는 아키텍처라면, 클라이언트-서버형 DB가 필요합니다. 이게 분기점입니다.

DB 레벨 사용자 권한이 필요하다면 SQLite는 안 됩니다

SQLite에는 사용자, 롤, 권한이라는 개념 자체가 없습니다. DB가 그냥 파일이기 때문에, 파일을 읽을 수 있는 사람은 전부 읽고, 쓸 수 있는 사람은 전부 씁니다. 접근 제어는 운영체제의 몫이죠.

1인용 데스크톱 앱이라면 이걸로 충분합니다. 하지만 DB 내부에서 사용자별로 권한을 다르게 줘야 하는 멀티테넌트 시스템이라면 PostgreSQL이나 MySQL로 가야 합니다.

SQLite 언제 사용해야 할지: 빠른 체크리스트

아래 항목을 하나씩 점검해 보세요. 전부 "예"라면 SQLite는 훌륭한 선택입니다:

• DB가 애플리케이션과 같은 머신에 있다.
• 하나의 프로세스(혹은 대부분 읽기만 하는 소수의 프로세스)가 DB에 접근한다.
• 전체 데이터가 디스크 하나에 충분히 들어간다 — 테라바이트도 괜찮지만, 어쨌든 디스크 한 개입니다.
• DB 레벨의 사용자 권한이 필요하지 않다.
• 동시 쓰기가 가끔 발생할 뿐, 주된 워크로드가 아니다.

하나라도 "아니오"가 나오면 Postgres나 MySQL을 검토하세요. 바로 다음 두 페이지에서 SQLite vs MySQL, SQLite vs PostgreSQL을 직접 비교합니다.

핵심 정리

• DB가 애플리케이션과 한 몸으로 동작하는 환경—데스크톱, 모바일, 임베디드 DB, CLI 도구, 테스트 스위트, 읽기 위주의 사이트, 로컬 캐시—에서는 SQLite가 정답입니다.
• SQLite는 충분히 프로덕션급입니다. 수십억 대의 기기에 탑재되어 있죠. 한계는 품질 문제가 아니라 아키텍처적인 제약입니다.
• 동시 쓰기가 많거나, 여러 머신에서 접근해야 하거나, 사용자별 DB 권한이 필요한 경우에는 다른 DB를 선택하세요.

다음: SQLite 설치하기

이론은 이쯤 하고, 다음 페이지에서는 SQLite를 실제로 설치해 봅니다. macOS와 대부분의 리눅스 배포판에는 이미 깔려 있고, Windows에서도 파일 하나 내려받으면 끝입니다. 설치 후 커맨드라인에서 제대로 동작하는지 확인하는 방법까지 함께 살펴보겠습니다.