정말 데이터베이스가 필요한가?

데이터는 결국 파일 위에 놓인다. 핵심 질문은 파일을 쓰느냐가 아니라, 직접 만든 파일 포맷을 쓸지 DB의 파일 구조를 쓸지다.

세 가지 저장 방식을 비교한다.

매 요청마다 파일 전체를 스캔: users.jsonl 같은 JSONL 파일을 열고 한 줄씩 파싱해 ID를 찾는다. 구조는 가장 단순하지만 O(n) 이라서 데이터가 커질수록 급격히 느려진다.
시작 시 메모리로 적재: 파일을 한 번 읽어 map/HashMap에 넣고, 쓰기는 메모리와 파일에 동시에 반영한다. 읽기는 O(1) 이고, 동시 읽기는 RWMutex/RwLock으로 잘 버틴다.
디스크 위 이진 탐색: ID로 정렬된 데이터 파일과 고정 폭 인덱스 파일을 두고 ReadAt으로 이진 탐색한다. 메모리에 전체를 올리지 않아도 되고, 조회는 O(log n) 이다.

벤치마크는 Go, Bun, Rust로 같은 HTTP 서버를 만들고 wrk로 10초 동안 측정했다. 데이터셋은 10k / 100k / 1M 레코드였다. 추가로 Go에서는 SQLite(modernc.org/sqlite) 도 비교했다.

결과는 분명하다.

선형 스캔은 데이터가 커질수록 붕괴한다. 1M 레코드에서 Go는 23 rps, Bun은 19 rps 수준까지 떨어진다.
메모리 맵이 가장 빠르다. Go는 약 97k rps, Bun은 106k rps, Rust는 169k rps까지 나온다. 지연시간도 서브밀리초다.
디스크 이진 탐색은 생각보다 강하다. Go에서 약 39k~46k rps, 평균 지연시간 1.2~1.4ms로 규모가 커져도 거의 평평하다.
SQLite도 안정적이다. 약 25k~26k rps, 평균 지연시간 2ms 안팎으로 데이터 크기에 덜 민감하다.
이 테스트에서는 손으로 짠 정렬 파일 + 인덱스가 SQLite보다 약 1.7배 빠르다. 단순 키 조회만 놓고 보면 DB 엔진의 범용성 비용이 보인다.

실무적 결론은 이렇다.

25,000 rps가 큰 숫자처럼 보이더라도, 일일 트래픽과 피크 비율, 사용자당 조회 수를 역산하면 생각보다 작은 서비스도 이 범위에 들어올 수 있다. 결국 저장 방식은 "DB가 있느냐 없느냐"보다 현재 규모와 앞으로의 질의 패턴에 맞춰 고르는 문제다.

핵심 내용