LatticeDB, 단일 파일·트랜잭션 행 지향 그래프 DB로 HN 공개

로컬 파일 하나를 쓰는 SQLite식 접근은 여러 용도에 맞아 보임. 지금까지 어느 정도 데이터 규모를 시험했고, 설계하면서 가장 재미있었던 부분이 뭔지 궁금함.

노드 100만 개로 성능을 재봤고, 지금은 에이전트 메모리 프로젝트에서 더 작은 규모로 주로 쓰는 중임. 디스크 쓰기조차 예상보다 복잡했고, LLM은 범위 있는 프로젝트를 만들게 해줬지만 테스트를 얕게 써서 통과해도 실제 기능이 깨진 경우가 있었음.

LadybugDB도 봐야 함. 스스로를 '그래프용 DuckDB'라고 부르는 프로젝트임.

KuzuDB가 Apple에 인수된 뒤 중단돼서 LadybugDB가 유망해 보임. 다만 Kuzu 팀이 유튜브에 올리던 자료는 아쉬움.

테이블을 가끔 그래프처럼 순회하려는 경우에는 DuckDB의 duckpgq가 더 유용한지 궁금함.

내 기준으로 duckpgq는 이미 있는 테이블을 가끔 순회할 때 쓰고, LatticeDB는 그래프 순회가 주된 질의일 때 씀. 에이전트 메모리에서 관련 기억을 찾는 그래프 RAG 용도로 LatticeDB를 백엔드 저장소로 쓰는 중임.

기여자 목록에 Claude가 보이는데, 실제로 얼마나 어떤 방식으로 썼는지 알고 싶음.

Claude와 Codex를 많이 썼음. 초반에는 설계와 파일시스템 기능을 하나씩 만들며 설명까지 받아 코드도 읽었고, 후반의 SIMD 같은 부분은 직접 리뷰하면 미묘한 버그를 놓칠 것 같아서 요구사항과 검증 방식에 더 집중했음.

Wikidata 같은 RDF 데이터를 넣는다면 RDF predicate를 노드-에지 모델의 에지로 매핑하면 되는지 궁금함.

나도 최근 그 방향을 많이 생각 중임. 회사에서도 그쪽으로 가고 있고, 그래프 저장 방식이 자연스럽다고 봄.

Wikidata가 RDF나 SPARQL을 강제하진 않음. Cypher로도 되고, 컬럼형 엔진이면 인덱스와 관계형 기능을 함께 얻을 수 있음.

왜 Kuzu를 포크해서 확장하지 않고 처음부터 만들었는지 궁금함.

직접 처음부터 만들어야 더 잘 배운다고 생각했음. 또 둘 다 단일 파일 그래프 DB이지만 LatticeDB는 트랜잭션 기반 행 지향이고 Kuzu는 컬럼 지향이라 데이터 배치도 다름.

단일 웹서버로 운영하고 몇 분 다운타임은 허용할 때 Litestream 같은 백업 방식을 지원하는지 궁금함.

그 의견을 보고 hot copy 기능을 거의 마무리했음. 문서만 정리해서 오늘 새 릴리스로 낼 예정임.

문서 접근 권한이 있으면 워크스페이스 아래 자식 문서도 자동으로 접근하게 하는 계층 권한을 그래프에서 어떻게 모델링할지 궁금함.

hasAccessTo, accessibleBy, childOf 에지를 두고 권한 확인 때 상위 루트까지 순회하는 방법이 있음. 다만 이 방식은 비즈니스 로직이라, 가능하면 노드별 권한을 반환하는 DB 함수를 만들어 감추는 편이 나음.

나는 ReBAC와 ABAC를 먼저 볼 것 같음. Casbin이나 SpiceDB 같은 그래프 기반 인가 시스템의 스키마는 의외로 단순해서 LatticeDB에도 구현할 수 있을 듯함.