HelixDB

핵심은 그래프 데이터와 벡터 데이터가 같은 저장소와 같은 트랜잭션에 산다는 점이다. 엣지와 임베딩을 함께 쓰거나, 둘 다 기록되지 않는다. 중간 상태는 없다. RAG 파이프라인에서 이는 백그라운드 동기화 작업이 중간에 죽었는데 일주일 동안 아무도 눈치채지 못해 벡터 인덱스와 관계 그래프가 조용히 어긋나는 고전적 장애를 없앤다.

HelixDB는 같은 데이터에 대해 그래프 순회, 벡터 검색, 전문 검색, 시간 질의를 실행한다. 의미적으로 비슷하고, 알려진 엔티티에 연결돼 있고, 최신인 문서를 한 번의 질의로 찾는다. 시스템 간 왕복이 줄면 지연이 낮아지고 코드가 단순해진다.

벡터와 전문 순위 단계 이전에 어떤 필터든 적용할 수 있다. 기술적으로 들리지만 실제 효과는 단순하다. 필터를 건 검색이 빠르고 정확하게 유지된다. 순위를 매긴 뒤 필터링하는 것은 검색 시스템에서 "나오면 안 되는 결과가 왜 나왔지"라는 버그의 흔한 원인이다.

그래프와 벡터 쓰기는 함께 커밋되거나 함께 롤백된다. 쓰기가 중간에 실패하면 임베딩이 저장되지 않은 콘텐츠를 가리키는 고아 엣지가 남지 않는다. 정리 스크립트도 필요 없다. 절반만 쓰인 인덱스를 디버깅해 본 사람이라면 이 보장이 말보다 값지다는 걸 안다.

HelixDB를 애플리케이션 안에서 라이브러리로 돌리거나, 자체 호스팅 서버로 세우거나, 관리형 배포를 쓸 수 있다. 같은 스키마와 질의가 세 가지 모두에서 동작한다. 덕분에 시제품이 다시 작성하지 않고 프로덕션으로 넘어갈 수 있다.

그래프와 벡터 데이터는 내구성 있는 객체 스토리지에 직접 영속된다. 이는 기술적 선택이자 비용 전략이다. 큰 임베딩 집합을 온라인에 유지하려고 비싼 블록 볼륨을 내는 대신 값싼 클라우드 스토리지에 기댈 수 있다.

HelixDB는 오프라인 분석만이 아니라 저지연 트랜잭션 읽기와 쓰기(OLTP)를 겨냥한다. 게이트웨이와 데이터베이스 노드를 확장해 고가용성도 지원하므로, 프로덕션 배포에 단일 장애점이 없다.