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

데이터베이스는 결국 파일 시스템 위의 구조화된 파일 집합이므로, 초기 단계의 애플리케이션은 직접 파일을 관리해도 충분히 빠를 수 있다.

동일한 HTTP 서버를 Go, Bun(TypeScript), Rust로 구현해 GET /users/:id 조회 성능을 비교했으며, 저장 방식은 크게 세 가지였다.

• 매 요청마다 파일 스캔: 요청마다 JSONL 파일을 끝까지 읽고 파싱하는 방식이라 O(n) 이며, 데이터가 커질수록 급격히 느려졌다.
• 인메모리 맵: 시작 시 전체 파일을 읽어 ID 기반 해시맵으로 올린 뒤 조회는 O(1) 로 처리했다. 가장 높은 처리량을 냈다.
• 디스크 이진 탐색: 정렬된 데이터 파일과 고정 폭 인덱스를 두고 ReadAt으로 O(log n) 탐색했다. RAM에 전체를 올리지 않아도 선형 스캔보다 훨씬 빠른 중간 해법이었다.

벤치마크는 10k / 100k / 1M 레코드, wrk 10초 테스트, Apple M1 Mac mini 환경에서 진행했다. Go는 추가로 SQLite(modernc.org/sqlite) 와도 비교했다.

핵심 결과는 다음과 같다.

• 선형 스캔은 1M 레코드에서 Go 23 req/s, Bun 19 req/s까지 떨어졌다.
• 디스크 이진 탐색은 10k~1M 구간에서 45k → 38k req/s로 감소폭이 작았다.
• SQLite는 약 25k req/s, 평균 지연 2ms로 안정적이었다.
• 인메모리 맵은 가장 빨라서 97k~169k req/s, 지연 0.5ms 이하를 기록했다.
• Rust 인메모리 맵이 최고 성능(169k req/s)이었고, Bun은 Go보다 약간 빨랐다.

저자는 이를 바탕으로, 대부분의 초기 제품은 별도 데이터베이스 없이도 단일 서버와 파일 저장만으로 충분하다고 주장한다. 간단한 서비스는 SQLite 단일 파일로도 매우 큰 트래픽까지 감당 가능하다고 본다.

다만 다음 조건이 생기면 데이터베이스가 필요해진다고 정리한다.

• RAM에 데이터가 다 안 들어갈 때
• ID 외 필드로 조회가 필요할 때
• 조인이 필요할 때
• 다중 프로세스 동시 쓰기가 필요할 때
• 원자적 엔터티 간 쓰기와 같은 ACID 보장이 필요할 때

부록으로는 Go, Bun, Rust 서버 코드와 시드/벤치마크 스크립트가 제공되며, DB Pro 제품 소개와 함께 SQLite, Postgres, 분산형 SQLite 관련 참고 글도 링크되어 있다.