SurrealDB 3.x 벤치마크 공개: Postgres, Mongo, Neo4j, Redis와 정면 비교

멀티 모델 DB가 정말 빠를 수 있을까

데이터베이스 세계는 늘 "전문성이냐, 통합성이냐" 사이에서 흔들려왔어요. 관계형 데이터는 PostgreSQL이 잘하고, 문서형은 MongoDB가 잘하고, 그래프는 Neo4j가 잘하고, 캐시는 Redis가 잘해요. 각자 자기 영역에서 수십 년간 최적화해온 강자들이죠. 그런데 "이 모든 걸 하나의 DB에서 다 하면 안 되나?"라는 야심찬 도전을 하는 신생 주자가 있어요. 바로 SurrealDB예요.

SurrealDB는 Rust로 짜인 멀티 모델 데이터베이스로, 관계형/문서/그래프/시계열 데이터를 하나의 엔진에서 다 다룬다고 주장해요. 흥미로운 콘셉트지만, 그동안 "진짜 빠른가?"라는 의심이 늘 따라다녔거든요. 일반적으로 멀티 모델 DB는 각 영역의 전문가 DB보다 느리다는 게 업계 통념이었으니까요. 그런데 이번에 SurrealDB가 3.x 버전의 공식 벤치마크 결과를 발표했어요. Postgres, Mongo, Neo4j, Redis와 정면으로 비교한 수치를 공개한 거죠. 게다가 fsync를 켠 상태에서의 비교라 의미가 더 커요.

fsync가 뭐길래 중요한가

벤치마크 이야기를 풀기 전에 fsync 개념부터 짚고 갈게요. fsync는 "방금 쓴 데이터를 디스크에 진짜로 강제로 내려쓰라"는 운영체제 명령이에요. 데이터베이스가 "저장 완료"라고 응답했는데 정전이 나면 어떻게 될까요? fsync를 안 했다면 그 데이터는 OS의 메모리 캐시에만 있다가 날아가 버려요. fsync를 했다면 디스크에 진짜로 박혀 있어서 살아남고요.

많은 DB 벤치마크가 fsync를 꺼놓고 측정해요. 그래야 숫자가 화려하게 나오거든요. 하지만 실제 프로덕션 환경에서는 데이터 안전성이 중요하니까 fsync를 켜는 게 보통이에요. 그래서 "fsync를 켠 벤치마크"는 "실제로 쓸 만한 성능"을 보여주는 더 정직한 측정이에요. SurrealDB가 굳이 이걸 강조한 건 "우린 화려한 가짜 숫자가 아니라 진짜 숫자로 승부한다"는 메시지인 셈이죠.

벤치마크 결과 살펴보기

SurrealDB가 공개한 수치를 큰 흐름으로 보면 이래요. 단순 쓰기와 읽기에서는 SurrealDB가 Postgres, Mongo와 비등하거나 일부 시나리오에서 더 빠른 결과를 보였어요. 이건 꽤 의미 있는 결과예요. 멀티 모델 DB가 전문 DB와 비슷한 속도를 낸다는 것 자체가 보통은 어려운 일이거든요.

그래프 쿼리에서는 Neo4j와 비교가 흥미로워요. Neo4j는 그래프 DB의 절대 강자인데, SurrealDB가 특정 패턴의 그래프 탐색에서 비슷하거나 더 나은 성능을 냈다고 해요. 다만 복잡한 그래프 알고리즘(PageRank, 최단경로 등)에서는 여전히 Neo4j가 강점을 보이는 영역이 있어요.

캐시 영역에서 Redis와 비교한 것도 도발적이에요. Redis는 in-memory 전용으로 만들어져서 압도적으로 빠른 게 정상인데, SurrealDB가 fsync를 켠 상태에서도 Redis와 비교될 만한 수치를 냈다는 건 놀라워요. 물론 Redis가 가진 정교한 데이터 구조(Sorted Set, HyperLogLog 등)나 Pub/Sub 같은 특수 기능까지 대체할 수 있다는 의미는 아니에요.

물론 벤치마크는 항상 "누가 측정했느냐"의 영향을 받아요. SurrealDB가 자체 발표한 수치니까 자기한테 유리한 시나리오를 선택했을 가능성도 있어요. 그래서 벤치마크 코드와 데이터셋을 공개한 부분이 중요해요. 다른 사람이 재현하고 검증할 수 있어야 진짜 신뢰할 수 있는 결과거든요.

기술적으로 어떻게 이게 가능한가

SurrealDB가 멀티 모델임에도 빠를 수 있는 비결은 몇 가지예요. 첫째, Rust로 짜였다는 점. Rust는 메모리 안전성을 유지하면서도 C/C++ 수준의 성능을 낼 수 있어서, GC(가비지 컬렉션)로 인한 지연이 없어요. Postgres는 C로 짜였고, Mongo와 Neo4j는 C++/Java라 GC나 메모리 관리에서 오버헤드가 있을 수 있죠.

둘째, 새로운 스토리지 엔진. SurrealDB는 SurrealKV라는 자체 키-값 스토리지를 만들었는데, LSM tree 구조에 현대적 최적화를 적용했어요. 또 RocksDB도 백엔드로 쓸 수 있게 되어 있어서 환경에 맞춰 고를 수 있어요.

셋째, 하나의 엔진에서 여러 모델을 다루는 통합 인덱스 구조. 보통은 그래프 쿼리를 하려면 별도 DB에 ETL(데이터 옮기기)을 해야 하는데, SurrealDB는 같은 데이터 위에서 SQL 같은 쿼리와 그래프 트래버설(노드 간 관계 따라가기)을 동시에 할 수 있어요.

업계 맥락에서 보면

멀티 모델 DB라는 카테고리에는 SurrealDB 외에도 경쟁자가 많아요. ArangoDB는 가장 오래된 멀티 모델 DB 중 하나고, OrientDB도 비슷한 컨셉이에요. 클라우드 진영에서는 FaunaDB, CockroachDB, TiDB 같은 분산 DB들이 또 다른 방향에서 도전하고 있어요. DuckDB나 EdgeDB 같은 후발 주자들도 각자의 색깔로 시장에 들어오고 있고요.

또 하나 주목할 흐름은 PostgreSQL의 확장성이에요. Postgres는 pgvector(벡터 검색), TimescaleDB(시계열), AGE(그래프) 같은 확장으로 사실상 멀티 모델화되어 가고 있어요. "통합 DB가 필요하면 새 DB를 쓰지 말고 Postgres 확장을 써라"는 주장도 강력해요. SurrealDB의 도전이 의미 있는 이유가 여기 있어요. 신생 멀티 모델 DB가 정말로 통합 가치를 증명하려면, 그냥 "확장된 Postgres"보다 명확히 나은 점을 보여줘야 하거든요.

한국 개발자에게 주는 시사점

첫째, 프로토타입이나 사이드 프로젝트에선 시도해볼 만해요. 작은 서비스에서 "DB를 4개 띄우기"는 운영 부담이 크거든요. SurrealDB 하나로 다 해결된다면 인프라가 단순해져요. 다만 프로덕션에 쓰기 전엔 본인 워크로드로 직접 벤치마크를 돌려봐야 해요.

둘째, 벤치마크를 읽는 눈을 키우세요. 벤더가 발표한 수치는 항상 "가장 유리한 시나리오"일 가능성이 높아요. 우리 회사의 진짜 쿼리 패턴, 데이터 크기, 동시성 조건에서 어떻게 동작하는지가 진짜 중요해요. fsync 같은 디테일까지 챙기는 벤더는 그래도 진정성이 있다고 볼 수 있고요.

셋째, Rust 기반 인프라 도구들의 시대가 오고 있어요. SurrealDB, ScyllaDB(C++이지만 비슷한 철학), Materialize, RisingWave 같은 데이터 인프라들이 새로운 세대의 성능 기준을 만들고 있어요. Rust를 한 번쯤 익혀두면 이런 도구들의 내부를 이해하는 데도 도움이 돼요.

마무리

"하나로 다 되는 DB"의 꿈은 오래된 환상이었지만, 이번엔 그 환상에 진지하게 도전하는 숫자가 나왔어요.

여러분 회사에서는 DB를 몇 개나 운영하고 계신가요? 만약 SurrealDB 같은 멀티 모델 DB로 통합한다면 어떤 워크로드가 가장 부담될 것 같으세요? 의견 들어보고 싶어요.