I don't care about your database benchmarks (and neither should you)

🖼️ 인포그래픽

I don't care about your database benchmarks (and neither should you) 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Convex는 데이터베이스 벤치마크 막대그래프 논쟁보다 실제 고객 워크로드, 비용, 지연 시간, 성장 이력에 기반한 투명한 확장성 설명이 더 유용하다고 주장한다.

📌 핵심 요약

글쓴이는 Convex가 이른바 ‘막대그래프 전쟁’에 참여하지 않겠다고 선언하며, 서로 다른 데이터베이스 시스템의 단순 성능 비교는 개발자 마케팅에는 좋을지 몰라도 실제 판단에는 낭비가 크다고 말한다.
첫 번째 이유는 벤치마크가 겉으로는 같은 성능을 재는 것처럼 보여도 실제로는 fsync, 쓰기 확인, ACID, 일관성, 복제, 장애 복구, 메모리 한계 등 전혀 다른 조건을 비교하는 경우가 많기 때문이다.
MongoDB, Redis, Postgres를 둘러싼 과거 논쟁 사례처럼, 높은 수치는 종종 서로 다른 내구성·복구·데이터 저장 방식의 결과였고, 결국 각 시스템이 다른 트레이드오프를 선택했음을 확인하는 데 그쳤다고 설명한다.
두 번째 이유는 합성 벤치마크가 제품 운영의 초점을 왜곡할 수 있기 때문이다. Convex는 처음부터 거대한 처리량을 목표로 하기보다 실제 고객과 잠재 고객의 필요보다 앞서 확장하고, 고객 피드백과 실제 워크로드를 기준으로 개선하는 방식을 택했다고 말한다.
Convex가 고객에게 제공해야 할 것은 경쟁사보다 모든 벤치마크에서 빠르다는 주장보다, 올해와 내년 예상 트래픽을 감당할 수 있는지, 비용이 얼마인지, 시간이 지나며 그 답이 좋아지는지를 실제 애플리케이션 기반 시나리오로 보여주는 투명성이라고 정리한다.

🧩 주요 포인트

글쓴이는 Convex가 이른바 ‘막대그래프 전쟁’에 참여하지 않겠다고 선언하며, 서로 다른 데이터베이스 시스템의 단순 성능 비교는 개발자 마케팅에는 좋을지 몰라도 실제 판단에는 낭비가 크다고 말한다.
첫 번째 이유는 벤치마크가 겉으로는 같은 성능을 재는 것처럼 보여도 실제로는 fsync, 쓰기 확인, ACID, 일관성, 복제, 장애 복구, 메모리 한계 등 전혀 다른 조건을 비교하는 경우가 많기 때문이다.
MongoDB, Redis, Postgres를 둘러싼 과거 논쟁 사례처럼, 높은 수치는 종종 서로 다른 내구성·복구·데이터 저장 방식의 결과였고, 결국 각 시스템이 다른 트레이드오프를 선택했음을 확인하는 데 그쳤다고 설명한다.
두 번째 이유는 합성 벤치마크가 제품 운영의 초점을 왜곡할 수 있기 때문이다. Convex는 처음부터 거대한 처리량을 목표로 하기보다 실제 고객과 잠재 고객의 필요보다 앞서 확장하고, 고객 피드백과 실제 워크로드를 기준으로 개선하는 방식을 택했다고 말한다.
Convex가 고객에게 제공해야 할 것은 경쟁사보다 모든 벤치마크에서 빠르다는 주장보다, 올해와 내년 예상 트래픽을 감당할 수 있는지, 비용이 얼마인지, 시간이 지나며 그 답이 좋아지는지를 실제 애플리케이션 기반 시나리오로 보여주는 투명성이라고 정리한다.

🧠 상세 정리

1. 막대그래프 벤치마크 논쟁에서 빠지겠다는 선언

글은 Convex가 데이터베이스 성능을 막대그래프로 겨루는 논쟁에 더 이상 참여하지 않겠다는 선언으로 시작한다. 글쓴이는 이런 비교가 개발자 마케팅에는 효과적일 수 있지만, 실제로는 팀의 시간을 소모하는 경우가 많다고 본다. Convex 팀이 대규모 요청을 처리하는 데이터베이스 시스템을 설계하고 운영해 본 경험이 있고, CPU 명령어, 캐싱 계층, 지연 시간 은닉 같은 세부 성능 기술도 이해한다고 전제한다. 그러나 경쟁사에도 훌륭한 데이터베이스 엔지니어가 있으며, 서로가 비슷한 최적화를 해낼 수 있다는 점에서 단순한 수치 대결은 핵심이 아니라고 말한다.

2. 벤치마크는 같은 것을 재는 것처럼 보여도 실제로는 다를 수 있다

첫 번째 비판은 서로 다른 시스템의 벤치마크가 흔히 ‘사과와 모루’를 비교하는 식이라는 것이다. CPU나 디스크 자체의 속도가 극단적으로 다르다기보다, 벤치마크가 실제로 측정하는 시스템 동작이 서로 다르기 때문에 큰 차이가 난다는 설명이다. 예를 들어 쓰기마다 fsync를 호출하는지, 클라이언트에 쓰기 완료를 확인해 주는지, ACID와 직렬화 수준을 어떻게 보장하는지에 따라 숫자는 크게 달라진다. 따라서 표면적으로는 같은 데이터베이스 처리량처럼 보이는 수치도, 실제로는 내구성·일관성·장애 허용 방식이 다른 결과일 수 있다.

3. 과거 MongoDB, Redis, Postgres 논쟁이 보여준 교훈

글쓴이는 2010년대 초반의 데이터베이스 벤치마크 논쟁을 사례로 든다. 당시 MongoDB는 데이터를 주기적으로 디스크에 쓰고 클라이언트 쓰기 확인을 하지 않는 방식으로 높은 수치를 보였고, Redis는 메모리 내 데이터셋과 긴 로그 재생 시간을 감수하는 설계로 빠른 숫자를 낼 수 있었다고 설명한다. 이런 설계 자체에는 쓰임새가 있지만, 이를 Postgres 같은 시스템과 단순 비교하며 낡은 기술이라고 조롱하는 것은 잘못된 비교였다는 것이다. 결국 논쟁을 파고들면 모두가 같은 기계에서 코드를 잘 쓸 줄 알지만, 서로 다른 시스템 동작을 만들거나 서로 다른 조건을 테스트하고 있었다는 사실로 돌아가게 된다고 정리한다.

4. 성능 차이를 이해하려면 원칙과 트레이드오프를 봐야 한다

글은 벤치마크를 해석하려면 숫자보다 먼저 어떤 조건이 달랐는지 확인해야 한다고 제안한다. 쓰기 확인, 레코드 경합, 엄격한 직렬화 같은 일관성 보장, 다중 가용 영역 복제, 장애 시 데이터 손실 허용 여부, 클라이언트의 요청 파이프라이닝이나 mutation 버퍼링이 모두 결과에 영향을 줄 수 있다. 또한 네트워크 왕복 시간이나 TLS 핸드셰이크만 재고 있는지, 메모리보다 큰 데이터셋을 지원하는지, 복구 시간이 상수 시간인지, 벤치마크 자체가 병목인지도 따져야 한다. 이런 차이를 하나씩 풀어내면 단순 순위가 아니라 시스템 설계 원칙과 선택한 트레이드오프가 드러나며, 그 과정 자체는 데이터베이스를 배우는 데 유익하다고 말한다.

5. 합성 벤치마크는 제품 관리의 초점을 흐릴 수 있다

두 번째 비판은 합성 벤치마크가 고객에게 좋은 제품을 만드는 판단을 방해할 수 있다는 점이다. Convex 팀이 매우 큰 규모의 시스템을 만들 수 있는 경험을 갖고 있더라도, 제품 초기부터 초당 1만, 10만, 100만 요청을 목표로 삼는 것이 항상 옳지는 않다고 말한다. 각 단계는 이전 단계보다 훨씬 많은 개발과 운영 시간을 요구하며, 신뢰성·일관성·내구성을 희생하지 않는다면 비용은 더 커진다. Convex의 첫 공개 버전은 실제로 초당 수십 요청 수준이었을 수 있고, 당시에는 그 수치를 정확히 재지 않았는데, 더 중요한 것은 누군가에게 쓸모 있는지를 확인하는 일이었기 때문이다.

6. 고객에게 필요한 투명성은 실제 워크로드 기반의 비용과 확장성이다

글쓴이는 Convex가 현재 고객과 잠재 고객의 필요보다 앞서 확장하는 것을 성공 기준으로 삼는다고 말한다. 고객이 Convex를 좋아하는지, 고객이 성장할 때 약속을 지키는지, 그리고 그 판단을 흐리게 하는 활동을 줄이는지가 더 중요하다는 입장이다. 이를 위해 Convex는 실제로 수십만 명 이상의 일간 활성 사용자를 가진 고객 애플리케이션을 바탕으로 몇 가지 시나리오를 설계하고, 각 플랜과 배포 클래스별로 건강한 사이트 경험을 유지할 수 있는 최대 요청률, 한 달 운영 비용, 시간에 따른 수치 개선 이력을 공개하려 한다. 모든 경쟁 벤치마크에서 가장 빠르다고 주장하지는 않지만, 많은 고객과 애플리케이션에는 경제적이고 신뢰할 수 있으며 생산적이고 충분히 빠른 선택지라는 점을 실제 데이터로 설명하려는 것이다.

🧾 핵심 주장 / 시사점

단순 RPS나 QPS 수치보다 tail latency, 비용, 장애·복구 조건, 일관성 보장 같은 맥락이 실제 서비스 판단에 더 직접적이다.
벤치마크를 무시하자는 주장이 아니라, 벤치마크 숫자를 만든 시스템 동작과 제품 트레이드오프를 먼저 해부해야 한다는 주장에 가깝다.
초기 제품의 확장성 목표는 최대 이론 성능이 아니라 현재 고객이 실제로 겪는 워크로드보다 앞서 있는지로 정해야 한다는 제품 운영 관점이 핵심이다.

✅ 액션 아이템

동일한 하드웨어·데이터셋·내구성 조건이 맞춰지지 않은 채 막대그래프만으로 DB를 우열짓지 않도록 비교 규칙을 정비한다.
실제 고객 워크로드·비용·지연 시간·성장 추세를 함께 추적하도록 테스트 산출서를 구성하고 운영 판단 기준으로 둔다.
MongoDB·Redis·Postgres 논쟁에서 드러난 내구성, 복구, 데이터 저장 방식 차이를 트레이드오프 항목으로 분리해 성능 수치의 의미를 정리한다.