• Turso는 Rust 기반 데이터베이스 코어에
  Postgres 호환 프런트엔드를 연결해, 하나의 실행 엔진이 여러 데이터베이스 언어를 처리하는데이터베이스의 LLVM구조로 확장함 - Postgres SQL을 공통 AST로 파싱해
  VDBE 바이트코드로 컴파일하며, 가능성을 검증한 pgmicro를 메인 코드 트리에 병합해 공식 개발 기반으로 삼음 - 기존 코어는 SQLite 파일 호환성, MVCC 동시 쓰기, 비동기 실행, 풍부한 타입 시스템,
  자동 갱신 구체화 뷰를 지원하며 여러 테스트 기법으로 신뢰성을 검증함 - 브라우저·모바일·각종 장치에서 임베디드 또는 단일 파일로 실행하면서도 기존 애플리케이션, ORM,
  psql

이Postgres 와이어 프로토콜로 접속할 수 있도록 설계함 - 100% 일치보다 널리 쓰이는 핵심 기능으로 기존 애플리케이션 대부분을 수정 없이 실행하는 데 집중하며, 확장 기능과 PL/pgSQL에는
WASM 및 호환 계층적용을 검토하고 MIT 라이선스로 개발함

Postgres를 Turso 위에 구축하는 이유

• Turso는 Rust로 작성된 현대적 데이터베이스 코어이며, 그 위에 Postgres 호환 데이터베이스를 처음부터 구축함

• 장기 목표는 기존 Postgres를 단순히 Rust로 옮기는 것이 아니라
  현대적 아키텍처를 갖춘 새로운 데이터베이스를 만드는 것임- 연결마다 별도 프로세스를 사용하지 않음

• 브라우저 안에서 임베디드 방식으로 실행할 수 있음

• 데이터베이스 하나를 단일 파일로 다룰 수 있음

• 구체화 뷰가 별도 작업 없이 자동으로 갱신됨

• 하나의 안정적인 코어에 여러 프런트엔드를 연결하는
  교체 가능한 컴파일 구조를 지향함- SQLite가 첫 번째 프런트엔드임

• Postgres가 다음 공식 프런트엔드임

• 향후 MySQL, Redis, 실험적 데이터베이스 같은 프런트엔드도 추가할 수 있음

• 현재 결과물은 완성된 제품이 아니라 실제로 실행할 수 있는
  개발 기반 단계임

SQLite 재구현에서 공통 데이터베이스 코어로

• Turso는 원래 SQLite를 Rust와 현대적 아키텍처로 완전히 재구현한 프로젝트이며, SQLite 파일을 열고 생성할 수 있는
  파일 호환성을 유지함 - SQLite의 범위를 넘어서는 기능도 이미 갖추고 있음
• Postgres처럼 MVCC를 이용한 동시 쓰기를 지원함
• Postgres와 유사한 풍부한 타입 시스템을 제공함
• 완전 비동기 방식으로 동작해 브라우저처럼 제약이 있는 환경에서도 네이티브 실행에 적합함
  구체화 뷰가 실시간으로 자동 갱신되므로REFRESH MATERIALIZED VIEW

크론 작업이나 트리거 조합이 필요하지 않음

• Postgres 프런트엔드가 추가돼도 기존 Turso와 SQLite의 목표는 달라지지 않음
• SQLite 완전 호환성과 미래 워크로드를 위한 기능 확장을 계속 추구함
• 필요한 기능을 구현할 때 Postgres 테스트도 활용할 수 있어 개발 속도를 높일 수 있음

신뢰성과 공개 기여 모델

• SQLite의 견고함을 재현하기 위해
  신뢰성을 제품 기능으로 취급함- 결정론적 시뮬레이션 테스트를 사용함

• Antithesis 테스트를 수행함

• Oracle 테스트, 퍼징, 형식 기법도 함께 적용함

• Turso에는 현재 260명 이상의 기여자가 있으며, 외부인도 프로젝트 방향에 참여할 수 있는
  **공개 기여(Open Contribution)**방식을 운영함 - 코드와 높은 품질 기준을 중심에 두고, 지속적으로 작업한 기여자가 프로젝트 의사결정에도 참여하는 Linux 커널식 환경을 지향함

• AI가 작성한 기여도 받아들이지만 충분한 품질을 갖춰야 하며, 사람이 코드를 면밀히 검토하고 아키텍처를 이해해야 함

SQLite 내부의 VDBE 가상 머신

• SQLite는 SQL을 직접 실행하는 단일 계층이 아니라 SQLite 방언의 SQL을
  VDBE 바이트코드로 컴파일해 실행하는 가상 머신 구조를 가짐 - VDBE는 JVM, .NET, WASM 같은 범용 바이트코드가 아니라
  B-tree에서 항목 찾기

처럼 데이터베이스에 특화된 고수준 연산을 제공함 - 이 바이트코드 언어에는 외부에 공개된 명세나 모듈식 인터페이스가 없지만 SQLite 내부에 실제로 존재하며, Turso도 같은 설계를 채택함

• Turso VDBE의 범용성을 검증하기 위해 작은
  C-to-VDBE 컴파일러로 Doom을 변환함- 실제 Turso 엔진을 WASM으로 컴파일해 브라우저 탭에서 Doom의 VDBE 바이트코드를 실행함
• 데이터베이스가
  SELECT

를 처리하는 것과 같은 방식으로 Doom을 실행함 - 각 프레임을 하나의 결과 행으로 처리함

• 메모리 영역은 읽고 쓸 수 있는 블롭으로 나타냄
• 구현은 turso-vdbe-doom-example 저장소에서 확인할 수 있음

Postgres 프런트엔드의 컴파일 구조

• 기존 SQLite와 Postgres 결합 시도는 SQLite의 모놀리식 구조 때문에 Postgres 쿼리를 SQLite 쿼리로 바꾸는
  쿼리 계층 번역에 주로 의존했으며, 두 데이터베이스의 외부 동작 차이로 임피던스 불일치가 컸음 - 내부적으로는 대부분의 SQL 데이터베이스가 B-tree와 인덱스 집합을 중심으로 비슷한 기본 연산을 수행함

• Postgres와 SQLite의 저장 구조에는 분명한 차이가 있음

• Postgres는 행을 힙 파일에 두고 별도의 B-tree 인덱스, 튜플 버전, TID, vacuum을 사용함

• SQLite는 데이터를 B-tree에 클러스터링함

• 이러한 차이는 주로 디스크에 바이트를 배치하는 방식에서 발생하며, Postgres에 필요한 연산은 기존 VDBE로 나타내거나 VDBE 명령을 확장해 지원할 수 있음

• 새 구조에서는
  데이터베이스 프런트엔드를 교체할 수 있음- Postgres 언어를 공통 AST로 파싱함

• AST를 Turso 바이트코드로 컴파일함

• 공통 Turso 코어가 바이트코드를 실행함

• 가능성을 검증한 초기 실험은 pgmicro로 진행했으며, 결과를 Turso 메인 코드 트리에 병합해 공식 프로젝트로 전환함

실행 형태와 활용 시나리오

• 같은 Postgres SQL과 데이터베이스 동작을 서버 없이 여러 형태로 제공하는 것이 목표임

• 브라우저 탭에서 실제 Postgres 호환 데이터베이스를 실행함

• 에이전트가 사용자마다 새 데이터베이스를 만들고 각각을 하나의 파일로 관리함

• 로컬 우선 애플리케이션이 Postgres 데이터를 단일 파일로 내려받은 뒤 다시 동기화함

• 모바일폰과 각종 장치에서 SQLite처럼 임베디드 방식으로 구동함

• 기존 Turso 데이터베이스를 로컬 파일에 동기화하는 기능도 Turso/Postgres에서 지원할 계획임

• 단일 파일·임베디드 실행뿐 아니라
  와이어 프로토콜과 서버 구현도 포함하므로 기존 애플리케이션, ORM,psql

이 연결할 수 있음 - 가까운 시기에 Turso 팀이 직접 개발할 공식 프런트엔드는 SQLite와 Postgres이며, 다른 프런트엔드는 외부 기여자가 만들 수 있도록 구조를 개방함

현재 실행 방법과 참여

• 아직 배포된 패키지는 없지만 소스에서 직접 빌드하고 실행할 수 있음
  cd postgres/cli && cargo run

• Postgres 프런트엔드는 별도 저장소가 아니라 Turso 코드 트리 안에서 첫날부터 공식 프런트엔드로 개발됨

• 개발과 기여는 Turso GitHub 저장소에서 진행함

호환성의 목표와 경계

• SQLite보다 훨씬 복잡한 Postgres의 특성상
  100% 호환성을 필수 목표로 삼지 않음 - 핵심 기능과 널리 쓰이는 기능을 충분히 지원해 대다수 사용자가 애플리케이션을 수정하지 않고 실행하도록 하는 데 집중함

• 현대적인 기능과 완벽한 1:1 호환성이 충돌하면 기능별로 판단함

• Turso의 구체화 뷰는 실시간 자동 갱신 방식임

• 완전한 호환성만을 위해 자동 갱신되지 않는 기존 방식까지 별도로 구현할지는 확정되지 않음

• 기능 범위가 늘어날수록 Turso/Postgres는 Postgres 복제품보다
  독자적인 데이터베이스에 가까워질 수 있음

AI 활용과 개발 속도

• AI 도구를 적극적으로 사용하되
  코드 검토와 아키텍처 이해를 생략하지 않음 - 데이터베이스처럼 중요한 구성 요소에서는 AI 도구가 검증 책임을 대체할 수준에 아직 도달하지 않았다고 판단함
• Fable을 24시간 실행하는 방식보다 커밋 단위 속도는 느릴 수 있지만, 이미 작동하고 광범위하게 테스트된 데이터베이스 코어에서 출발함
• 빠르게 변경하다 시스템을 깨뜨리기보다
  느리더라도 올바르게 구현하는 방식을 선택함 - 모든 기능을 완성하려면 시간이 필요하며, 일부 기능은 적절한 아키텍처가 자리 잡을 때까지 긴 개발 과정을 거쳐야 함

PL/pgSQL과 확장 기능

• PL/pgSQL은 구현 불가능한 요소가 아닌 절차형 언어이지만, 그대로 재구현하기보다
  별도의 절차형 언어와 호환 계층을 제공할 가능성이 큼 - 일부 Postgres 확장 기능을 WASM 컨테이너에서 불러오는 개념 증명을 확보함

• WASM 컨테이너가 제공하는 심볼만 사용하는 확장 기능은 임의로 불러올 수 있음

• WASM 실행에 따른 성능 손실이 있음

• 아직 최종 설계로 확정된 방식은 아님

• 임의 코드를 제한 없이 실행하게 하는 확장 시스템은 바람직하지 않다고 판단함

• 일부 확장 기능은 지원하지 못할 수 있지만, 많은 확장 기능은 WASM으로 컴파일하면 불러올 수 있을 것으로 봄

예상 일정과 오픈소스 전략

• 처음부터 새 데이터베이스를 만드는 대신, 이미 작동하고 테스트됐으며 Postgres와 내부 구조를 상당 부분 공유하는 코어에서 시작함

• 모든 Postgres 기능을 구현하려면 오랜 시간이 걸릴 수 있지만, 실무에 유용한
  충분히 큰 기능 부분집합은 수개월 안에 제공할 수 있을 것으로 예상함 - 두 핵심 개발자는 현재 약 44세이며 앞으로 최소 20년 동안 개발할 수 있으므로 전체 기능 완성을 서두르지 않음

• 실제 개발 속도와 범위는 커뮤니티 기여에 크게 좌우됨

• SQLite 방언의 다중 프로세스 지원 당시 팀에 Windows 장비가 없어 Windows 구현을 제외함

• Turso를 많이 사용하던 외부 개발자 한 명이 관심을 갖고 일주일 안에 Windows 지원을 완성함

• 실험적 프런트엔드는 코드 트리 밖에서 개발될 수 있지만, 공식 Postgres 프런트엔드에는 기존 Turso와 동일한
  MIT 라이선스를 적용함