Hacker News 의견

• 나는 SQLite 기반의 hybrid protobuf ORM/CRUD 서버를 만들고 있음
  코드와 설명은 GitHub - accretional/collector에 있음
  실시간 백업 시 5~15ms 다운타임, 수백 개의 읽기/쓰기 요청 큐잉, CRUD 전체 지연 1ms 수준, WAL 기반 스트리밍 백업까지 가능함
  예전엔 Postgres와 Spanner만 썼는데, Collector에 파티션 기능만 추가되면 Postgres는 다시 안 쓸 것 같음

  • BTRFS 같은 atomic snapshot 파일시스템을 써서 SQLite + WAL로 제로 다운타임 백업을 하는 방법도 고려해봤는지 궁금함. 스냅샷 후 천천히 백업하고 삭제하면 됨

• 단점은 모든 데이터와 연산이 단일 머신에 들어가야 한다는 점임
  AWS의 u-24tb1.112xlarge 인스턴스(448 vcore, 24TB RAM, 64TB EBS)를 쓰면 꽤 여유가 있음

  • 하지만 Hetzner의 베어메탈 서버를 빌리면 코어당 성능이 2~3배, 비용은 90% 절감됨
  • SQLite의 이론적 최대 DB 크기는 281TB라고 공식 문서에 명시되어 있음. 실제로는 파일시스템 한계가 더 작지만, 동작은 정상임
  • 단일 머신 스케일업은 안정적이지만 탄력성(elasticity) 이 떨어짐. 트래픽 급증 시 과할당하거나 장애를 감수해야 함
  • “데이터가 RAM에 들어가나?”를 묻는 yourdatafitsinram.net 링크를 보면, 고성능 단일 노드라면 EC2보단 전용 서버가 낫다고 생각함

• 글에서 SQLite의 효율성을 강조했지만, 비교 기준이 불명확하다고 느낌
  원래 분리된 서버 구조를 전제로 하다가, 로컬 임베디드 DB 성능을 측정했기 때문임
  같은 조건이라면 로컬 Postgres 튜닝으로도 비슷한 성능을 낼 수 있음

  • SQLite는 같은 머신의 Postgres보다도 빠름. 실제 배포 환경에서의 구성을 기준으로 테스트하는 게 타당함
  • SQLite를 요청 핸들러 뒤에 감싸서 다른 서버에서 돌릴 수도 있음. 결국 DB는 요청 처리기와 저장소의 조합일 뿐임
  • 단일 박스에서 원시 처리량(raw throughput) 이 중요함. SQLite는 PG보다 10배 빠르고, PG는 트랜잭션 복잡도가 높을수록 느려짐
  • “그럼 SQLite는 비교 대상이 아니다”라는 말은 너무 단순함. 글이 너무 짧아질 것임
  • SQLite는 모바일이나 임베디드뿐 아니라 저동시성 서버 앱에도 적합함. 웹 서버만을 위한 DB는 아님

• Postgres 연결 수를 8개로 제한한 건 병목일 수 있음
  CPU와 스레드 사용량을 함께 공개하고, 더 큰 커넥션 풀로 재테스트하면 좋겠음

  • 커넥션 풀을 코어 수(8)에 맞춘 건 괜찮지만, 트랜잭션 내 sleep이 있으면 병목이 생김
    64개 연결로 늘리면 처리량이 8배 늘 수도 있음. 한계에 도달할 때까지 클라이언트 설정을 확장해야 함
  • 이 글의 수치는 믿기 어려움. 나는 네트워크 기반 MySQL에서도 훨씬 높은 TPS를 내고 있음

• 핵심은 네트워크 지연이 병목인지 인식하는 것임
  많은 워크로드에서 평범한 로컬 DB가 훌륭한 원격 DB보다 빠름
  중요한 건 “어떤 DB가 최고냐”가 아니라 “네트워크 경계를 넘을 필요가 있느냐”임

  • (작성자) 맞음. SQLite vs Postgres 논쟁이 아니라, 네트워크 기반 DB의 한계를 다루려 했음
  • 물론 모든 걸 메모리에 두고 Redis나 Memcache를 쓰면 성능은 쉽게 높아짐. 하지만 그건 규칙이 달라지는 것임

• 네트워크형 DB는 앱 재배포가 쉬운 장점이 있음
  새 인스턴스를 띄우고 기존 걸 종료하면 거의 무중단 배포가 가능함
  SQLite를 같은 인스턴스에 두면 교체 시 DB를 다시 올려야 해서 더 복잡함. 실제 운영에서 이런 문제를 겪었는지 궁금함

  • SQLite를 프로덕션에서 쓰려면 영구 스토리지와 NVMe가 필요함. 보통은 베어메탈 단일 서버로 운영함
    마이그레이션 시에는 다운타임이 생길 수 있음. Litestream 덕분에 이제는 복제와 백업이 쉬워졌음
  • SQLite는 멀티 프로세스 접근을 지원하므로, 새 프로세스를 띄우고 기존 걸 종료하는 식의 무중단 교체도 가능함

• 작성자가 PRAGMA synchronous="normal"로 설정했는데, 이는 fsync를 매번 수행하지 않음
  공정한 비교를 위해 "full"로 설정해야 함

  • 하지만 WAL 모드에서는 "normal"도 괜찮음. 전원 손실 시 내구성은 잃지만 트랜잭션의 일관성은 유지됨

• SQLite의 HA(고가용성) 구성은 어떻게 되는지 궁금함
  최소한 자동 장애 조치가 가능한 수준은 되어야 함

  • SQLite는 C 라이브러리이므로, rqlite, litestream, litefs 같은 프로젝트로 확장 가능함
    나는 현재 Postgres와 SQLite(litestream 포함) 중 고민 중임.
    내 앱은 약간의 다운타임이 허용되므로, 단일 박스에서 수직 확장하는 게 더 단순하고 저렴함
  • 최근엔 Marmot이라는 멀티마스터 프로젝트가 2년 만에 부활했음.
    Marmot GitHub에 gossip 기반 복제 메커니즘이 새로 추가됨

• 실제로 SQLite를 프로덕션에서 한계까지 밀어붙인 사례가 있는지 궁금함

  • Expensify의 사례가 가장 극단적인 예시임

• 일반적인 웹앱이나 커머스 환경에서 SQLite vs Postgres의 사용자 수 한계가 어느 정도인지 궁금함
  SQLite는 최근 업데이트로 동시 읽기는 가능하지만 단일 쓰기만 허용됨
  어떤 경우에 이것이 문제가 되는지, 그리고 확장을 고려한다면 Postgres로 시작하는 게 나은지 의견을 묻고 싶음