SQLite-on-the-Server에 대한 오해: 작은 규모보다 초대형(Hyper-Scale) 규모에 더 적합

• 많은 개발자들이 서버에서 SQLite를 사용하는 것은 소규모 애플리케이션에나 어울린다고 생각
• 그 이유는 다음과 같음:
  • 낮은 인프라 비용: 별도의 데이터베이스 서버가 필요하지 않음 (단일 파일로 운영)
  • 개발 및 테스트 용이: 동일한 DB 파일을 클라이언트와 서버에서 활용 가능
  • 관리 부담 최소화: 복잡한 설정이나 데몬 관리가 불필요
  • 높은 신뢰성: SQLite는 전 세계에서 가장 많이 배포된 DB이며, 강력한 내구성을 가짐
• LiteFS, Litestream, rqlite, Dqlite, Bedrock 등의 도구가 SQLite에 복제(replication) 및 고가용성(HA)을 추가하여 소규모 배포에 적합하게 만들어줌

하지만 이 글에서는 소규모가 아닌 초대형 애플리케이션(Hyper-Scale)에 적합한 SQLite의 가능성을 탐구함

기존의 대형 데이터베이스 확장 문제

• 대형 애플리케이션은 보통 PostgreSQL, MySQL을 단일 DB로 유지하기 어려워 샤딩(Sharding)된 데이터베이스를 사용
• 예: Cassandra, ScyllaDB, DynamoDB, Vitess(샤딩된 MySQL), Citus(샤딩된 Postgres)
• 샤딩된 DB는 다음과 같은 장점을 가짐:
  • 데이터 파티션을 통해 배치 읽기(Batch Read) 최적화
  • 수평적 확장(Scalability) 가능
  • 고속 쓰기 성능 제공

하지만 현재의 파티셔닝 솔루션에는 다음과 같은 단점이 존재

• 고정된 스키마(Rigid Schemas): MySQL이나 Postgres처럼 유연한 쿼리를 지원하지 않음
• 스키마 변경이 어려움: 인덱스 추가나 관계 변경 시 운영 부담이 큼
• 복잡한 크로스 파티션 연산: ACID 트랜잭션을 유지하기 어렵고, 두 단계 커밋(2PC) 같은 복잡한 기법 필요
• 데이터 불일치 문제: 파티션 간 강력한 데이터 제약 조건을 적용하기 어렵고, 데이터 정합성이 깨질 가능성이 높음

SQLite 기반 하이퍼스케일 데이터베이스의 가능성

• Cloudflare Durable Objects와 Turso는 SQLite를 기반으로 하이퍼스케일 애플리케이션을 설계하는 방식을 보여줌
• 이들 시스템은 다음과 같은 강점을 제공함:
  • 동적 확장(Dynamic Scaling): 엔터티(Entity)별로 데이터베이스를 생성하여 인프라 복잡성을 감소
  • 무제한의 저비용 데이터베이스: 기존 샤딩처럼 데이터 파티션을 강제하지 않고, 필요할 때마다 새로운 SQLite 인스턴스를 생성 가능
  • 글로벌 분산(Global Distribution): 데이터베이스를 사용자 가까운 위치에 배치하여 성능 향상
  • 내장된 복제 및 내구성(Built-in Replication & Durability): 기존 SQLite와 달리 다중 지역에서 데이터를 복제하여 고가용성 유지
• SQLite를 활용한 샤딩 대체 방식 (Cloudflare Durable Objects & Turso 활용)
  • 기존 샤딩 방식에서는 단일 데이터베이스 파티션에 여러 채팅 로그 저장
  • SQLite를 사용하면 각 채널별로 독립적인 SQLite 데이터베이스를 생성하여 보다 유연한 스키마 활용 가능
  • 예제 구조
    • 기존 샤딩: 채팅 로그 테이블 + 파티션 키
    • SQLite 기반: 채널별 개별 SQLite DB (채팅 로그, 참여자, 반응 정보 포함)
• SQLite를 사용한 이 방식의 장점은 다음과 같음:
  • 로컬 ACID 트랜잭션 유지: 크로스 파티션 문제 없이 개별 DB 내에서 트랜잭션 수행 가능
  • 고성능 I/O: SQLite는 단일 파일 DB이므로, 읽기 및 쓰기 성능이 매우 뛰어남
  • SQL 확장 기능 활용 가능:
    • FTS5(Full-Text Search): 검색 성능 향상
    • JSON1: JSON 데이터 저장 및 쿼리 지원
    • R*Tree, SpatiaLite: 공간 데이터 활용 가능
  • SQL 마이그레이션 지원: Prisma, Drizzle 같은 기존 마이그레이션 도구와 호환 가능
  • 느린(Lazy) 스키마 마이그레이션 지원:
    • 마이그레이션 실행이 즉시 필요하지 않고, SQLite 인스턴스를 열 때 가벼운 마이그레이션을 수행하는 방식 사용 가능

서버에서 SQLite를 사용할 때의 한계점

• 오픈소스, 자체 호스팅 가능한 솔루션 부족
• 크로스 데이터베이스 쿼리 미지원 → 분석을 위해서는 별도의 데이터 레이크 필요
• 제한된 데이터베이스 툴링 (SQL 브라우저, ETL 파이프라인, 모니터링, 백업)
  • StarbaseDB가 Cloudflare Durable Objects + SQLite 기반으로 이 문제 해결 중
• 통합된 표준 프로토콜 부족
  • PostgreSQL, MySQL, Cassandra는 표준화된 프로토콜을 사용하지만, SQLite 서버는 아직 표준화된 네트워크 프로토콜이 부족
• 하이퍼스케일에서 SQLite를 사용한 대규모 사례 부족
  • Cassandra, DynamoDB 같은 사례 연구가 부족하지만, 시간이 지나면서 변화할 가능성이 있음

결론: SQLite는 단순한 로컬 DB가 아닌, 초대형 애플리케이션에서도 강력한 옵션

• SQLite는 단순한 소규모 프로젝트용 DB가 아니라, 초대형 애플리케이션에서도 기존 샤딩 방식을 대체할 수 있는 강력한 도구
• Cloudflare Durable Objects & Turso를 활용하면, 데이터베이스를 엔터티 단위로 분할하여 SQL의 강력한 기능과 ACID 트랜잭션을 유지하면서 확장 가능
• 전통적인 샤딩된 데이터베이스보다 더 유연하고 관리가 쉬운 대안으로 자리 잡을 가능성이 높음