SQLite, 이제 프로덕션에서 써도 됩니다 - 2026년 신규 프로젝트와 MVP에 최적인 이유

"SQLite는 테스트용 아니야?"

몇 년 전까지만 해도 맞는 말이었다. 하지만 2026년 현재, SQLite를 프로덕션에서 쓰는 서비스가 급격히 늘고 있다. Rails 8이 SQLite를 기본 DB로 밀고 있고, Turso, Litestream 같은 도구들이 등장하면서 MVP나 신규 프로젝트에서 SQLite를 선택하는 게 더 이상 이상한 일이 아니게 됐다.

SQLite가 달라진 점

최신 버전 (3.51.x, 2025년)

• jsonb_each(), jsonb_tree() - JSON 처리 강화
• unistr() - 유니코드 문자열 함수 추가
• sqlite3_setlk_timeout() - 락 타임아웃 세밀한 제어
• 성능 최적화 - 읽기 트랜잭션 커밋 속도 개선
• IN 연산자 최적화 - 서브쿼리 재사용 개선

25주년 기념 릴리스 (3.50.0)

2025년 5월에 나온 25주년 버전에서 대대적인 개선이 있었다. SQLite 팀이 "이제 웹 앱에서도 써도 된다"고 자신감을 보인 버전이다.

왜 갑자기 SQLite가 뜨는 걸까?

1. 하드웨어가 빨라졌다

SQLite 전문가 Ben Johnson의 벤치마크에 따르면, 현대 SSD에서 SQLite는 초당 수만 건의 읽기/쓰기가 가능하다.

읽기: 초당 400,000+ 쿼리
쓰기: 초당 10,000+ 쿼리 (WAL 모드)

대부분의 웹 앱은 이 정도면 충분하고도 남는다.

2. WAL 모드의 등장

WAL(Write-Ahead Logging) 모드가 게임 체인저였다.

PRAGMA journal_mode=WAL;

• 읽기와 쓰기가 동시에 가능
• 읽기 성능 대폭 향상
• 동시 접속 처리 능력 향상

3. Litestream으로 백업 문제 해결

SQLite의 가장 큰 약점이었던 "백업/복제"가 해결됐다.

Litestream은 SQLite의 WAL 변경사항을 S3 같은 스토리지로 실시간 스트리밍한다.

# litestream.yml
dbs:
  - path: /data/myapp.db
    replicas:
      - url: s3://mybucket/myapp

• 1초 단위 백업 가능
• Point-in-time 복구 지원
• 재해 복구 시간 2분 이내

4. Rails 8의 공식 지원

Rails 8이 SQLite를 1급 시민으로 대우하기 시작했다.

# Rails 8 기본 설정
rails new myapp  # SQLite가 기본!

• Solid Queue (백그라운드 잡) - SQLite 지원
• Solid Cache (캐시) - SQLite 지원
• Solid Cable (웹소켓) - SQLite 지원

Redis 없이 Rails 앱을 운영할 수 있게 됐다.

SQLite vs PostgreSQL/MySQL 비교

항목 SQLite PostgreSQL/MySQL

설치	파일 하나	서버 설치 필요
운영	없음	DBA 필요할 수 있음
비용	$0	서버 비용 + 관리 비용
백업	파일 복사 (+ Litestream)	pg_dump, mysqldump
동시 쓰기	1개 (순차 처리)	다수
복제	Litestream, Turso	네이티브 지원
확장성	단일 서버	수평 확장 가능

언제 SQLite를 선택해야 할까?

SQLite가 딱 맞는 경우

1. MVP / 프로토타입

- 빠른 개발이 중요
- 인프라 고민 최소화
- 나중에 마이그레이션 가능

2. 1인 개발 / 소규모 팀

- 서버 관리할 여력이 없음
- 월 $5 VPS로 운영하고 싶음
- 복잡한 인프라 싫음

3. 읽기 위주 서비스

- 블로그, 문서 사이트
- 읽기 90% 이상인 서비스
- 컨텐츠 중심 앱

4. 임베디드 / 로컬 앱

- 데스크톱 앱
- 모바일 앱
- CLI 도구

5. 엣지 컴퓨팅

- Cloudflare Workers
- Fly.io 엣지 배포
- 각 리전에 로컬 DB

SQLite를 피해야 하는 경우

• 초당 수천 건 이상의 쓰기
• 복잡한 트랜잭션이 많은 금융 서비스
• 여러 서버에서 동시 쓰기 필요
• 팀에서 PostgreSQL/MySQL 경험이 풍부

실제 운영 사례

Joy of Rails

- SQLite로 런칭
- 3개월 운영
- DB 관련 장애 0건
- PostgreSQL로 전환 계획 없음

37signals (Basecamp, HEY)

Rails 8의 SQLite 지원은 37signals의 경험에서 나왔다. 실제 대규모 서비스에서 검증된 설정이다.

벤치마크 결과 (Rails 8 기준)

일일 10만 히트 이상 처리 가능
N+1 쿼리가 PostgreSQL보다 덜 치명적
(네트워크 레이턴시가 없어서)

SQLite 프로덕션 설정 가이드

1. WAL 모드 활성화

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA busy_timeout=5000;
PRAGMA cache_size=-20000;  -- 20MB 캐시

2. Rails 8 설정

# config/database.yml
production:
  adapter: sqlite3
  database: storage/production.sqlite3
  pool: 5
  timeout: 5000

3. Litestream 설정

# litestream.yml
dbs:
  - path: storage/production.sqlite3
    replicas:
      - type: s3
        bucket: my-backup-bucket
        path: db/production.sqlite3
        sync-interval: 1s

4. Kamal 배포 (Rails 8)

# config/deploy.yml
volumes:
  - "myapp_storage:/rails/storage"

볼륨을 마운트해서 DB 파일을 영속화한다.

Turso - SQLite의 클라우드 버전

SQLite 호환 분산 데이터베이스 Turso도 주목할 만하다.

import { createClient } from "@libsql/client";

const client = createClient({
  url: "libsql://my-db.turso.io",
  authToken: "..."
});

const result = await client.execute("SELECT * FROM users");

• SQLite 호환 SQL
• 글로벌 복제
• 엣지 배포
• 무료 티어 제공

MVP 빠르게 시작하기

Rails 8

rails new myapp
cd myapp
rails generate scaffold Post title:string body:text
rails db:migrate
rails server

끝. PostgreSQL 설치도 없고, Docker도 필요 없다.

Node.js (Better-sqlite3)

const Database = require('better-sqlite3');
const db = new Database('myapp.db');

db.exec(`
  CREATE TABLE IF NOT EXISTS users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    email TEXT UNIQUE
  )
`);

const insert = db.prepare('INSERT INTO users (name, email) VALUES (?, ?)');
insert.run('Kim', 'kim@test.com');

Python (sqlite3 내장)

import sqlite3

conn = sqlite3.connect('myapp.db')
cursor = conn.cursor()

cursor.execute('''
    CREATE TABLE IF NOT EXISTS users (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        name TEXT NOT NULL,
        email TEXT UNIQUE
    )
''')

cursor.execute('INSERT INTO users (name, email) VALUES (?, ?)', 
               ('Kim', 'kim@test.com'))
conn.commit()

자주 묻는 질문

Q: 동시 접속 많으면 어떡해요?

읽기는 무한대로 동시 가능하다. 쓰기만 순차 처리되는데, WAL 모드에서는 초당 1만 건 이상 처리 가능하다. 대부분의 웹 앱은 이 정도면 충분하다.

Q: 서버 죽으면 데이터 날아가지 않나요?

Litestream으로 S3에 실시간 백업하면 최대 1초 분량만 손실된다. PostgreSQL의 WAL 백업과 비슷한 수준의 안정성을 확보할 수 있다.

Q: 나중에 PostgreSQL로 옮기기 어렵지 않나요?

기본적인 SQL은 호환된다. Rails나 Django 같은 ORM을 쓰면 마이그레이션이 더 쉽다. 다만 PostgreSQL 전용 기능(JSONB, Array, 확장 등)은 못 쓴다.

Q: 어느 정도 규모까지 가능해요?

- 일일 10만 히트: 여유 있음
- 일일 100만 히트: 가능 (최적화 필요)
- 그 이상: PostgreSQL 고려

정리

상황 추천

MVP / 프로토타입	SQLite ✓
1인 개발 사이드 프로젝트	SQLite ✓
읽기 위주 서비스	SQLite ✓
스타트업 초기	SQLite ✓ (나중에 전환 가능)
대규모 쓰기 트래픽	PostgreSQL
복잡한 분석 쿼리	PostgreSQL
팀에서 PG 경험 풍부	PostgreSQL

2026년의 SQLite는:

• 프로덕션에서 써도 되고
• MVP에 최적이며
• 인프라 비용을 극적으로 줄일 수 있다

복잡하게 생각하지 말자. 월 $5 VPS 하나에 앱과 DB를 같이 올리고, Litestream으로 S3에 백업하면 끝이다.

나중에 진짜 스케일이 필요해지면 그때 PostgreSQL로 옮겨도 늦지 않다. 대부분의 서비스는 그 "나중"이 안 온다.