DoltLite: Git식 버전 관리를 얹은 SQLite 포크, 에이전트 PR 2천 개로 만들었다

Who Should Read

SQLite를 임베디드 DB로 쓰면서 데이터 branch·diff·롤백이 필요하거나, 에이전트가 DB를 건드리는 상황이 걱정되는 백엔드 개발자

Core Mechanics

• SQLite에서 저장 계층만 갈아 끼웠다
  • SQL 파서, 분석기, 파일 시스템 계층, 테스트 하네스는 stock SQLite 그대로다.
  • B-tree 계층만 단일 파일 chunk store 기반 Prolly Tree(내용 주소 지정 B-tree)로 교체했다.
• SQLite에 Git 기능이 들어왔다
  • 로컬에서 branch, merge, diff, rebase, cherry-pick, reset을 지원한다.
  • 원격은 push, pull, clone, fetch를 지원하고 DoltHub를 sync 백엔드로 쓸 수 있다.
• SQL 호환성 테스트는 거의 통과
  • sqllogictest(복잡한 쿼리 580만 개)는 100% 통과했다.
  • SQLite의 TCL 인수 테스트 892,277개는 99.46% 통과, 알려진 차이는 4,809건이다.
  • 차이 사유는 rowid 대신 primary key 사용, page 대신 chunk 사용, WAL/journal 파일 없음이다.
• 읽기는 비슷하고 쓰기는 느리다
  • 인메모리 DB는 SQLite 대비 읽기 10%, 쓰기 60% 느리다.
  • 파일 DB는 읽기가 동급이고 배치 쓰기가 10% 느리다.
  • 작은 autocommit 쓰기는 3.1배 느려서 SQLite 약 125µs, DoltLite 약 400µs다(작은 GitHub runner 기준).

Community Reactions

• 테스트 신뢰도에 대한 회의론
  • 1.2~4배 느린 데다 SQLite 수준의 검증은 어려울 거라는 의견이 있었다.
  • 에이전트로 만든 DB에 데이터를 맡기기 싫다는 의견도 여럿이었다.
• 더 단순한 대안 제시
  • DB 파일 복사나 copy-on-write 파일 시스템, SQLite VFS로 fork하는 편이 만들기·실행·검증 모두 쉽다는 의견이 있었다.
• local-first 앱에 쓸 만하다는 반응
  • 모든 기기에서 동기화되는 로컬 우선 음악 앱을 만들려는 사람이 기대를 밝혔다.
• 빠진 것과 궁금증
  • Go 클라이언트가 없는 점이 가장 큰 한계라는 의견이 있었다.
  • 어떻게 이 정도로 자동화했는지, 서브에이전트를 썼는지 묻는 댓글도 있었다.

How to Apply

• 기존 SQLite 파일로 호환성 먼저 돌려보기
  • 오늘 로컬에서 DoltLite를 설치하고 운영 DB 사본을 열어 주요 쿼리를 돌려 보자.
  • rowid, page, WAL에 직접 의존하는 코드가 있는지 grep으로 확인하자.
• 에이전트 작업 전에 브랜치를 따고 실패 시 reset하기
  • 에이전트가 DB를 수정하는 작업 앞에서 브랜치를 만들고 결과를 diff로 확인하자.
  • 문제가 있으면 dolt_reset('--hard')로 되돌리자.
• 쓰기 패턴을 배치로 바꿔 벤치마크하기
  • autocommit 단건 쓰기를 트랜잭션 단위 배치로 묶어 SQLite와 같은 부하로 비교하자.
  • 작은 autocommit 쓰기가 3.1배 느리므로 이 구간을 먼저 측정하자.
• 오프라인 동기화 요구에 push/pull 시험하기
  • 기기 간 sync가 필요한 프로토타입에서 DoltHub를 원격으로 두고 push, pull, clone을 돌려 보자.
  • 충돌 처리 방식이 요구에 맞는지 확인하자.

Try It

# Claude 또는 ChatGPT에 붙여넣기 (원문 방법을 프롬프트로 옮긴 체크리스트)

나는 SQLite를 쓰는 서비스를 DoltLite(SQLite 포크, Git식 버전 관리, B-tree 대신 Prolly Tree)로 바꿔 볼지 검토 중이다.
원문에서 확인된 사실: SQL 계층은 stock SQLite, 테이블은 rowid 대신 primary key 기준, page 대신 chunk 사용, WAL/journal 파일 없음, 작은 autocommit 쓰기 3.1배 느림, 읽기는 파일 DB 기준 동급.

내 서비스 정보:
- 스키마: {{스키마}}
- 주요 쿼리 패턴: {{쿼리 패턴}}
- 쓰기 방식(autocommit/배치 여부, 초당 쓰기 수): {{쓰기 패턴}}
- WAL, rowid, page 관련 코드 사용 여부: {{사용 여부}}

위 사실만 근거로 다음을 표로 정리해 줘:
1. 깨질 수 있는 코드 지점
2. 쓰기 성능 영향이 클 지점과 배치로 바꾸는 방법
3. 먼저 돌려볼 테스트 5개

이어서 해 볼 것: 결과에서 1번 항목을 실제 코드 grep 명령으로 바꿔 달라고 요청해 보자.

Terminology

관련 논문

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓

Related Resources

• https://www.dolthub.com/blog/2026-08-31-doltlite-beta/