Git처럼 쓰는 SQL DB, Dolt 2.0이 가져온 변화
Dolt는 Git의 브랜치, 커밋, 머지 개념을 SQL 데이터베이스에 그대로 적용한 오픈소스 프로젝트다. 테이블 단위로 변경 이력을 추적하고, 브랜치를 나눠 스키마나 데이터를 독립적으로 수정한 뒤 머지할 수 있다. 데이터 마이그레이션 실수나 배포 롤백이 빈번한 환경에서 이 접근 방식은 실질적인 안전망이 된다. 이번 2.0 릴리스는 그 기반 위에 운영 부담을 줄이는 자동화 기능을 얹었다는 점에서 주목할 만하다.
자동 GC와 압축, 왜 운영 관점에서 중요한가
버전 관리 데이터베이스의 고질적인 문제 중 하나는 스토리지 증가다. 커밋이 쌓일수록 참조되지 않는 오래된 데이터 조각들이 남고, 이를 주기적으로 정리하지 않으면 디스크 사용량이 빠르게 불어난다. 기존 Dolt에서는 가비지 컬렉션을 수동으로 트리거하거나 스크립트로 자동화해야 했다.
2.0에서는 GC와 압축이 자동으로 실행된다. 불필요한 스토리지 오브젝트가 백그라운드에서 정리되고, 저장 데이터는 자동 압축으로 효율이 높아진다. 운영 관점에서 이는 단순히 편의성의 문제가 아니다. 수동 GC를 잊거나 타이밍을 놓쳤을 때 발생하는 디스크 풀, 혹은 정리 작업 중 성능 저하 같은 리스크가 구조적으로 제거된다.
-- Dolt에서 브랜치 기반 작업 예시
CALL dolt_checkout('-b', 'feature/new-schema');
ALTER TABLE orders ADD COLUMN discount DECIMAL(5,2);
CALL dolt_commit('-am', 'Add discount column to orders');
CALL dolt_merge('feature/new-schema');
대용량 및 벡터 데이터 타입 지원 강화
2.0의 또 다른 축은 대용량 데이터 타입과 벡터 데이터 타입에 대한 지원 개선이다. 현대 백엔드 시스템은 단순한 정형 데이터 외에도 BLOB, TEXT, 그리고 고차원 벡터 데이터를 함께 다루는 경우가 늘고 있다. 이런 데이터를 버전 관리 없이 별도 스토리지에만 두면, 코드·스키마·데이터 간의 이력 추적이 분리되어 디버깅이나 롤백 시 일관성을 보장하기 어렵다.
Dolt 2.0은 이 격차를 좁히는 방향으로 나아갔다. 데이터 집약적인 파이프라인이나, 임베딩·특징 벡터를 DB에 함께 저장하는 구조를 채택한 팀이라면 버전 관리의 이점을 더 넓은 범위에서 누릴 수 있게 된다.
정리
- Dolt 2.0은 GC와 압축 자동화로 버전 관리 DB의 스토리지 운영 부담을 구조적으로 줄였다
- 브랜치·커밋·머지 기반의 데이터 변경 관리는 스키마 마이그레이션 사고나 데이터 롤백 시나리오에서 실질적인 안전망이 된다
- 대용량·벡터 데이터 타입 지원 강화로 정형 데이터 외 다양한 워크로드에서의 활용 가능성이 넓어졌다