SQLite 가 잘못된 선택인 경우

잘못된 도구가 되는 자리

SQLite 를 정직하게 옹호하려면 명백히 잘못된 도구인 케이스를 짚어야 돼. 다음 상황엔 Postgres / 다른 네트워크 DB 로 가:

여러 머신의 여러 writer — SQLite 는 파일 한 개 안에서 write 를 직렬화해. 로드 밸런서 뒤의 다중 앱 서버가 같은 logical DB 에 다 쓰는 워크로드는 Postgres 영역.
네트워크 접근 필수 — 데이터를 다른 호스트의 클라이언트에서 query 해야 하면 server 가 필요. SQLite 엔 빌트인 네트워크 프로토콜이 없어.
세분화된 user 단위 인증 / row-level security — Postgres 는 풍부한 RBAC + RLS. SQLite 는 파일시스템 권한이 다야.
매우 큰 dataset + hot write — read-heavy / append-heavy 면 TB 도 거뜬한데, 동시 수천 writer 가 OLTP 로 두드리는 10 TB 시스템은 진짜 DB 서버 영역.
Out-of-the-box replication / HA — Postgres 는 streaming replication + 매니지드 서비스가 어디나 있음. SQLite 는 Litestream / LiteFS / Turso 로 추가하는데 semantics 가 달라.
RBAC — multi-tenant SaaS 에서 tenant 별로 SQL-level 자격증명으로 격리해야 하는 경우.

Warning: 가장 흔한 SQLite 사고 = 로드 밸런싱 된 여러 서버 뒤에 SQLite 두고 replication 레이어 없이 굴리는 거. 서버마다 자기 사본이 생기고 silently 갈라져. NFS, GlusterFS, '그냥 rsync 로 처리' 떠올린다면 멈춰 — 다른 DB 쓰거나 Litestream / Turso 도입.

SQLite 는 scale 한다 의 정직한 버전: SQLite 는 single node 위에서 vertically + read-wise 로 사람들이 생각하는 것보다 훨씬 잘 scale 해. 동시 writer 를 위한 horizontal scale 은 진짜 replication 레이어 없으면 안 돼, 그렇다고 우기지도 않아.

Code

'한 번에 하나의 writer' 가 어떻게 보이나·python

# 두 프로세스가 동시에 쓰려고 하면, 두번째가 첫번째 commit 까지 잠깐 block.
# WAL + busy_timeout 이면 일반 트래픽에선 OK.
# 많은 프로세스가 hot-loop 으로 쓰면 병목.
import sqlite3, time, threading

def writer(name):
    conn = sqlite3.connect('contention.db', timeout=5.0)
    conn.execute('PRAGMA journal_mode=WAL')
    conn.execute('CREATE TABLE IF NOT EXISTS log(id INTEGER PRIMARY KEY, who TEXT, t REAL)')
    for _ in range(1000):
        conn.execute('INSERT INTO log(who, t) VALUES (?, ?)', (name, time.time()))
        conn.commit()
    conn.close()

threading.Thread(target=writer, args=('A',)).start()
threading.Thread(target=writer, args=('B',)).start()

Exercise

Postgres / MySQL 쓰는 서비스 하나 골라. 그 워크로드의 어떤 속성 (네트워크 접근, multi-writer, RBAC 등) 이 SQLite 부적합 사유인지 짚어. 그 다음 질문: 아키텍처를 다시 짠다면 (per-user DB, edge runtime, tenant 별 sharding) SQLite 가 viable 했을까? 디자인의 어디가 바뀌어야 했을까?

SQLite 가 잘못된 선택인 경우

잘못된 도구가 되는 자리

Code

External links

Exercise

Progress

댓글 0