HydraDB 리뷰

AI 에이전트에 기억을 붙이려면 어딘가에 담아둬야 합니다. 대화가 오간 순서, 어떤 상품을 봤고 뭘 물어봤는지, 그 사이의 연결. 벡터 데이터베이스에 문장 조각을 넣어두는 방식이 흔한데, 관계를 따라가야 할 때는 잘 안 맞습니다.

그래서 조간에 HydraDB 가 올라왔을 때 열어봤습니다. "가장 빠르고 싸다" 를 내걸고 코어를 공개한 그래프 데이터베이스¹라고 합니다. 반증할 수 있는 주장이라 확인해보고 싶었어요.

그래프가 사는 곳은 디스크가 아니라 S3 입니다

로컬 SSD 는 캐시일 뿐이고, 오브젝트 스토어가 유일한 내구성 있는 사본입니다.

구조가 이 물건의 전부입니다. 보통 데이터베이스는 자기가 붙어 있는 디스크에 데이터를 씁니다. HydraDB 는 오브젝트 스토리지²에 씁니다.

저장소 문서의 표현이 정확하더군요.

그래프 레코드, WAL³, 매니페스트, 변하지 않는 순회 인덱스가 전부 S3 호환 스토리지에 삽니다.

그리고 이렇게 못 박아뒀어요.

오브젝트 스토어는 이 계층 전체 아래 깔린 공용 층이고, 그래프의 유일한 내구성 있는 사본입니다.

질의를 처리하는 노드에도 로컬 SSD 가 붙어 있는데 그건 캐시일 뿐입니다. 노드가 죽어도 그래프는 S3 에 남아 있고, 새 노드가 올라와 캐시를 다시 만들어냅니다.

라임 테두리 웅덩이 하나에 펌프가 붙어 있습니다.

싸다는 말이 여기서 나옵니다. 그래프가 커질수록 비싼 디스크를 크게 붙여야 하는 구조가 아니라, S3 를 키우면 되는 구조니까요. 연산 노드와 인덱서를 따로 늘릴 수 있다는 것도 같은 이야기입니다.

클라이언트 쪽은 익숙하게 만들어뒀습니다. Neo4j 드라이버를 Bolt⁴ 5.x 로 그대로 붙일 수 있고 OpenCypher⁵ 를 씁니다. 쓰던 코드를 크게 안 고쳐도 된다는 뜻이에요.

싸진 만큼 읽기에서 값을 치릅니다

공식 문서가 내놓은 읽기 모드 두 가지입니다.

공짜는 아닙니다. 데이터가 S3 에 있다는 건 최신 값을 보려면 S3 까지 다녀와야 한다는 뜻이니까요.

문서가 이걸 숨기지 않고 읽기 모드 두 개로 내놨습니다.

• causal — 노드가 지금 갖고 있는 읽기 시점을 그대로 씁니다. 문서가 "기본이고 빠른 경로"라고 적었어요.
• strong — 질의를 고정하기 전에 오브젝트 스토리지에서 읽기 시점을 새로 고칩니다. 문서 표현으로는 "오브젝트 스토어까지 다녀오는 신선도 비용을 냅니다."

쇼핑몰로 옮기면 이런 겁니다. 상품 설명을 읽어 오는 화면이면 causal 로 충분해요. 방금 들어온 주문이 보여야 하는 화면이면 strong 을 써야 하고, 그 순간 S3 왕복이 붙습니다.

싸다는 말과 빠르다는 말이 같은 자리에 있지 않습니다. 어느 쪽을 고를지는 화면마다 다릅니다.

어디를 읽느냐에 따라 다른 물건입니다

같은 제품을 설명하는 세 곳을 나란히 놓았습니다.

자료를 모으다가 이상한 걸 봤어요. 같은 제품인데 어디서 읽느냐에 따라 말이 다릅니다.

저장소 README 에는 속도나 비용에 대한 주장이 하나도 없습니다. "왜 HydraDB 인가" 라는 절이 있는데 거기 적힌 건 내구성, 따로 늘어나는 연산, 안전한 쓰기 주인 넘김, 일관된 읽기 같은 기술적인 이야기뿐이에요. 빠르다는 말도, 싸다는 말도 안 나옵니다.

홈페이지는 다릅니다.

지연이 낮은 앱을 위해 만들었습니다 — HydraDB 로 실시간 애플리케이션을 만드세요. < 200ms 아주 빠르고, 멀티테넌트이며, 오브젝트 스토리지 위에 세웠습니다.

재현율 92%, LongMemEval-S 90% 이상, 투자 유치 650만 달러, 누적 적재 10억 건 같은 숫자도 여기 있습니다.

둘 다 같은 회사가 씁니다. 그런데 받아서 쓰는 사람이 보는 건 저장소이고, 고를지 말지 정하는 사람이 보는 건 홈페이지예요. 저는 저장소 쪽이 더 믿을 만하다고 봅니다. 거기 적힌 게 검증 가능한 구조 설명이라서요.

공식 벤치마크에는 비교 대상이 없습니다

저장소 배지에 걸린 벤치마크 사이트의 시험 조건입니다.

저장소 배지에 benchmarks: live 가 달려 있어서 눌러봤어요.

재는 항목은 그럴듯합니다. 순회 깊이별 지연, worker 수에 따른 처리량, 쓰기 비용, 캐시 영향. 그런데 조건을 보고 멈췄어요.

• 하드웨어: 15코어 머신 한 대
• 스토리지: 같은 호스트의 Docker 안에서 돌린 MinIO
• 벤치마크를 언제 돌렸는지 날짜가 없습니다
• 다른 데이터베이스와 견주는 내용이 없습니다. 자기 성능만 보여줍니다

마지막 둘이 중요합니다. 이 제품의 핵심 주장은 "오브젝트 스토리지에 두니까 싸다"인데, 벤치마크는 오브젝트 스토리지가 네트워크 너머에 있는 상황을 안 재봤습니다. 같은 컴퓨터 안의 MinIO 는 진짜 S3 가 아니에요. 진짜 S3 는 왕복 지연이 붙고, 그게 strong 읽기의 비용이 되는 바로 그 지점입니다.

비교가 없는 것도 그렇고요. "가장 빠르다"는 비교급인데, 공식 벤치마크는 비교를 안 합니다. 홈페이지가 세게 적은 걸 벤치마크가 뒷받침해주지 않는 모양이에요.

이건 벤치마크가 틀렸다는 말이 아닙니다. 자기 성능 곡선을 보여주는 자료로는 정직합니다. 다만 "제일 빠르고 싸다"의 근거로 쓰기에는 조건이 모자랍니다.

라이선스가 AGPL 입니다

상황마다 다르게 걸립니다.

실무에서 제일 중요한 대목은 여기라고 봅니다.

AGPL-3.0 이에요. MIT 도 Apache 도 아닙니다. 저장소 배지와 LICENSE 파일에 그렇게 적혀 있습니다. 앞서 본 다른 도구들이 MIT 였던 것과 갈리는 지점입니다.

AGPL 이 다른 이유는 하나입니다. 네트워크 너머로 서비스하는 것까지 배포로 봅니다. 서버에 올려두고 고객이 브라우저로 쓰게 하는 것도 배포에 들어간다는 뜻이에요. MIT 는 그렇지 않습니다.

사무실에서 우리끼리 쓰는 건 문제가 없고요. 고객사 제품에 넣거나 우리가 서비스로 굴리는 자리라면 이야기가 달라져요. 홈페이지에 Enterprise 등급이 "BYOC 와 완전 자체 호스팅" 으로 따로 있는 게 그 자리를 위한 것으로 보입니다.

저희는 변호사가 아닙니다. 고객사 일에 넣을 생각이면 법무 검토를 먼저 받는 게 맞습니다. 이 글에서 드릴 수 있는 건 "라이선스가 AGPL 이니 그냥 넘어가지 마세요" 까지입니다.

지금 생각

구조는 재미있게 봤습니다. 그래프를 S3 에 두고 노드는 캐시만 갖는다는 발상, 그리고 그 대가를 causal / strong 으로 정직하게 갈라놓은 것. 문서가 자기 비용을 숨기지 않아서 읽기 좋았어요.

2026-09-08 에 조회한 저장소 상태입니다.

다만 지금 붙이기에는 이릅니다.

첫째, 저장소가 아직 어립니다. 2026년 7월 3일에 열렸고, 기여자가 7명, 릴리스 태그가 하나도 없습니다. 받아 쓰려면 main 을 직접 빌드해야 하는데, 버전을 못 박을 수 없다는 건 고객사 일에서는 불편합니다. 최근 커밋도 3주쯤 전이고 대부분 CI 정리였습니다.

둘째, AGPL 을 정리하고 시작해야 합니다. 이건 기술 문제가 아니라 계약 문제라 나중에 되돌리기가 어렵거든요.

셋째, 우리 규모에서 이 구조가 이득인지 모르겠습니다. 오브젝트 스토리지에 두는 게 싸지는 건 그래프가 아주 클 때입니다. 쇼핑몰 하나의 주문·상품·고객 관계는 그렇게까지 크지 않아요. 요금제를 보면 월 $399 에 그래프 저장 10GB 인데, 그 정도 크기면 평범한 DB 로도 충분합니다.

모르는 채로 남는 건 진짜 S3 를 붙였을 때 strong 읽기가 실제로 얼마나 걸리는지입니다. 공식 벤치마크가 같은 호스트 MinIO 로 쟀으니 그 숫자에는 안 들어 있어요. 네트워크 너머 오브젝트 스토리지를 상대로 재본 기록을 아직 못 찾았습니다. 좀 더 나오면 그때 다시 보려고 합니다.