@thomas0가 대규모 마이그레이션을 꼼꼼히 맡아줬고, @355E3B는 계획과 운영을 도왔으며, #539 관련 기여자와 #lobsters 덕분에 읽기 전용 시간도 즐겁게 넘길 수 있었음
원래 #539에서는 PostgreSQL을 계획했지만, 실제 작업 지원자가 SQLite를 사용했고 예상 수요보다 크고 복잡한 해법을 피하고 싶어 SQLite를 선택함. PostgreSQL은 평소 기본 선택이지만 별도 서비스를 운영·조정·유지해야 하는 부담이 있음
놀랍게도 마이그레이션 후 CPU와 RAM 사용량이 모두 감소했으며, 자세한 차트는 #539 마지막 부분에 있음

SQLite의 기본 설정을 볼 때마다 놀라게 됨. WAL, 외래 키, synchronous=NORMAL 등을 기본으로 제공하는 신규 프로젝트용 모드가 있으면 좋겠고, 이 밖에도 개선할 기본값이 더 있을 듯함

디스크 변경의 예약이나 형식이 HDD에는 유리하지만 NVMe에는 상당히 부적합했던 부분도 있었던 것으로 희미하게 기억함

SQLite 데이터베이스의 백업 전략이 궁금함. litestream 같은 도구를 사용하는지, 다른 방식을 쓰는지 알고 싶음

SQLite의 update 문을 사용함. 다른 종류의 업데이트를 뜻했다면 구체적으로 알려주길 바람

SQLite에는 이미 iif 함수가 있지만, 같은 영역에서 사용자 정의 함수를 운영하는 것 자체도 흥미로움

SQLite가 PostgreSQL이나 MySQL과 같은 수준의 동시성을 지원하지 못한다고 생각했는데, 개요 문서를 보면 이제 여러 프로세스에서 사용할 수 있되 lobste.rs는 단일 서버에서 실행해야 한다고 이해하면 되는지 궁금함
프로세스들이 공유 메모리나 mmap 같은 방식으로 SQLite 내부에서 동기화되어 동시에 쓰기는 하나만 가능하고 읽기는 여러 개 허용되는지, 대기 중인 쓰기 작업은 큐에서 차례를 기다리는지도 알고 싶음

SQLite FAQ가 일부 의문에 답해줄 수 있음. 여러 프로세스에 걸쳐 여러 읽기 작업을 수행할 수 있지만 쓰기는 한 번에 하나만 가능하고, SQLite는 파일 시스템 잠금으로 이를 보장함
쓰기 대기에는 명시적인 공유 메모리 큐가 아니라 잠시 대기한 뒤 재시도하는 방식이 쓰이는 듯함. 여러 머신에서 SQLite를 쓰는 것이 완전히 불가능한지는 확실하지 않지만, NFS로 파일을 공유하는 단순한 접근은 명시적으로 권장되지 않으므로 단일 서버라고 이해하는 것이 합리적인 근사치이며 요즘은 한 대로도 상당한 규모를 처리할 수 있음

쓰기 작업을 어느 정도 대기시키기는 하지만 기본 설정은 좋지 않아서 조정이 필요함. 현재 사용하는 설정은 다음과 같고, busy_timeout이 작동하도록 즉시 트랜잭션 모드도 켜야 함