Rails 8 + SQLite — 프로덕션에서 써도 되는 이유
PostgreSQL 없이도 되는 시대가 왔다 — 37signals가 증명한 SQLite 프로덕션 운영
Rails 8부터 SQLite가 프로덕션 환경에서 공식적으로 추천되는 데이터베이스가 되었다. "SQLite는 개발용"이라는 인식은 이제 과거다.
왜 지금 SQLite인가?
Rails 8에서 도입된 Solid 시리즈(Solid Queue, Solid Cache, Solid Cable)가 게임 체인저다. 이전에는 Redis(캐시, 잡 큐)와 PostgreSQL(DB)을 따로 운영해야 했지만, 이제 SQLite 하나로 DB + 캐시 + 잡 큐 + 웹소켓까지 전부 처리할 수 있다.
37signals(Basecamp, HEY 개발사)가 이 구성을 실제 프로덕션에서 사용하고 있다. DHH(Rails 창시자)가 직접 "대부분의 웹 앱에 PostgreSQL은 과잉"이라고 말한 바 있다.
SQLite가 프로덕션에서 되는 이유
- 서버리스 — 별도 프로세스/포트 없이 파일 하나로 동작. DB 서버 관리가 필요 없다
- WAL 모드 — Write-Ahead Logging으로 읽기/쓰기 동시성이 크게 개선됨
- Solid 시리즈 — Redis/Memcached 없이 SQLite 기반으로 캐시·잡·케이블 전부 처리
- 배포 간소화 — DB 서버 설정, 커넥션 풀 관리, 마이그레이션 순서 걱정 불필요
- 비용 절감 — RDS/CloudSQL 같은 매니지드 DB 비용이 제로
- 백업 간단 — 파일 복사 한 번이면 전체 백업 완료
언제 PostgreSQL이 여전히 필요한가?
동시 쓰기가 매우 많은 앱 (초당 수천 건 이상의 INSERT)
다중 서버에서 같은 DB에 접근해야 하는 경우 (SQLite는 단일 서버)
jsonb, Full Text Search, PostGIS 등 PostgreSQL 전용 기능이 필요한 경우
이미 PostgreSQL 기반 인프라가 구축된 대규모 팀
대부분의 중소규모 앱, 1인/소규모 팀 프로젝트, SaaS MVP, 사이드 프로젝트에는 SQLite가 충분하다.
Rails 8 Solid 시리즈 — Redis/PostgreSQL 없이 전부 SQLite로
| 기능 | 이전 (Rails 7) | 현재 (Rails 8) |
|---|---|---|
| 데이터베이스 | PostgreSQL / MySQL | SQLite (WAL 모드) |
| 백그라운드 잡 | Sidekiq + Redis | Solid Queue (SQLite) |
| 캐시 | Redis / Memcached | Solid Cache (SQLite) |
| WebSocket | Action Cable + Redis | Solid Cable (SQLite) |
| 필요한 외부 서비스 | PostgreSQL + Redis (최소 2개) | 없음 (파일만) |
SQLite vs PostgreSQL — 언제 뭘 쓸까?
| 기준 | SQLite | PostgreSQL |
|---|---|---|
| 서버 구성 | 단일 서버 (파일 기반) | 별도 DB 서버 필요 |
| 동시 쓰기 | WAL로 개선됐지만 한계 있음 | MVCC로 높은 동시성 |
| 읽기 성능 | 매우 빠름 (네트워크 홉 없음) | 빠름 (네트워크 레이턴시 있음) |
| 스케일링 | 수직만 (서버 스펙 업) | 수평 + 수직 (리플리카 추가) |
| 운영 비용 | $0 (파일) | $15~100+/월 (매니지드) |
| 백업 | 파일 복사 한 번 | pg_dump 또는 매니지드 스냅샷 |
| 전용 기능 | json (jsonb 미지원) | jsonb, PostGIS, FTS, Array, Enum |
| 적합한 규모 | 1인~소규모 팀, MVP, 사이드 프로젝트 | 중대규모 팀, 고트래픽, 다중 서버 |
주의사항 — SQLite 프로덕션 운영 시
jsonb 타입 사용 금지
SQLite는 jsonb를 지원하지 않는다. 마이그레이션에서 t.jsonb 대신 반드시 t.json을 사용해야 한다.
볼륨 마운트 필수 (Docker/Kamal 배포 시)
SQLite 파일이 컨테이너 안에 있으면 재배포 시 데이터가 날아간다. 반드시 호스트 볼륨에 마운트해야 한다.
WAL 모드 확인
Rails 8은 기본으로 WAL 모드를 설정하지만, 기존 프로젝트를 업그레이드한 경우 config/database.yml에서 명시적으로 확인해야 한다.
백업 자동화
파일 복사로 간단하지만, 쓰기 중 복사하면 깨질 수 있다. sqlite3 .backup 명령어 또는 Litestream을 사용하면 안전한 실시간 백업이 가능하다.
다중 서버 구성 불가
SQLite 파일은 하나의 서버에서만 접근 가능하다. 로드 밸런서 뒤에 여러 앱 서버를 두는 구성에서는 PostgreSQL이 필요하다.
SQLite 추천
- ✓ 1인 또는 소규모 팀
- ✓ SaaS MVP, 사이드 프로젝트
- ✓ 인프라 비용을 최소화하고 싶을 때
- ✓ 읽기 위주 앱 (블로그, 문서 사이트)
- ✓ 단일 서버로 충분한 트래픽
PostgreSQL 추천
- ✓ 초당 수천 건 이상의 동시 쓰기
- ✓ 다중 서버 구성 필요
- ✓ jsonb, PostGIS, FTS 등 전용 기능 필요
- ✓ 이미 PostgreSQL 인프라가 있는 팀
- ✓ 수평 스케일링 계획이 있는 서비스
핵심 포인트
Rails 8 프로젝트 생성 시 기본 DB가 이미 SQLite (별도 설정 불필요)
config/database.yml에서 WAL 모드 활성화 확인 (Rails 8 기본 설정)
Solid Queue(잡), Solid Cache(캐시), Solid Cable(웹소켓) 활성화
Kamal 또는 Fly.io로 배포 — DB 서버 설정 자체가 없음
jsonb 대신 json 타입 사용 (SQLite는 jsonb 미지원)
장점
- ✓ 인프라 구성 제로 — DB 서버, Redis, Memcached 전부 불필요
- ✓ 배포 간소화 — 파일 복사만으로 DB 이전 가능
- ✓ RDS/CloudSQL 비용 제로 — 매월 수만원 절약
- ✓ 레이턴시 최소 — 네트워크 홉 없이 디스크 직접 접근
- ✓ 37signals가 실제 프로덕션에서 검증
단점
- ✗ 단일 서버 전용 — 다중 서버에서 동시 접근 불가
- ✗ 동시 쓰기 병목 — 대량 INSERT 시 성능 저하 가능
- ✗ jsonb, PostGIS, Full Text Search 등 PostgreSQL 전용 기능 미지원
- ✗ 수평 스케일링 불가 — 트래픽 폭증 시 수직 스케일링만 가능