# Rust로 Postgres 만들기 — 데이터베이스의 LLVM을 활용한 접근 > Clean Markdown view of GeekNews topic #31529. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31529](https://news.hada.io/topic?id=31529) - GeekNews Markdown: [https://news.hada.io/topic/31529.md](https://news.hada.io/topic/31529.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-18T07:03:23+09:00 - Updated: 2026-07-18T07:03:23+09:00 - Original source: [turso.tech](https://turso.tech/blog/a-new-modern-version-of-postgres-in-rust) - Points: 1 - Comments: 1 ## Topic Body - Turso는 Rust 기반 데이터베이스 코어에 **Postgres 호환 프런트엔드**를 연결해, 하나의 실행 엔진이 여러 데이터베이스 언어를 처리하는 **데이터베이스의 LLVM** 구조로 확장함 - Postgres SQL을 공통 AST로 파싱해 **VDBE 바이트코드**로 컴파일하며, 가능성을 검증한 pgmicro를 메인 코드 트리에 병합해 공식 개발 기반으로 삼음 - 기존 코어는 SQLite 파일 호환성, MVCC 동시 쓰기, 비동기 실행, 풍부한 타입 시스템, **자동 갱신 구체화 뷰**를 지원하며 여러 테스트 기법으로 신뢰성을 검증함 - 브라우저·모바일·각종 장치에서 임베디드 또는 단일 파일로 실행하면서도 기존 애플리케이션, ORM, `psql`이 **Postgres 와이어 프로토콜**로 접속할 수 있도록 설계함 - 100% 일치보다 널리 쓰이는 핵심 기능으로 기존 애플리케이션 대부분을 수정 없이 실행하는 데 집중하며, 확장 기능과 PL/pgSQL에는 **WASM 및 호환 계층** 적용을 검토하고 MIT 라이선스로 개발함 --- ### Postgres를 Turso 위에 구축하는 이유 - [Turso](https://github.com/tursodatabase/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](http://antithesis.com) 테스트를 수행함 - 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](https://github.com/tursodatabase/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 명령을 확장해 지원할 수 있음 - 새 구조에서는 **데이터베이스 프런트엔드를 교체**할 수 있음 1. Postgres 언어를 공통 AST로 파싱함 2. AST를 Turso 바이트코드로 컴파일함 3. 공통 Turso 코어가 바이트코드를 실행함 - 가능성을 검증한 초기 실험은 [pgmicro](https://github.com/glommer/pgmicro)로 진행했으며, 결과를 Turso 메인 코드 트리에 병합해 공식 프로젝트로 전환함 ### 실행 형태와 활용 시나리오 - 같은 Postgres SQL과 데이터베이스 동작을 서버 없이 여러 형태로 제공하는 것이 목표임 - 브라우저 탭에서 실제 Postgres 호환 데이터베이스를 실행함 - 에이전트가 사용자마다 새 데이터베이스를 만들고 각각을 하나의 파일로 관리함 - 로컬 우선 애플리케이션이 Postgres 데이터를 단일 파일로 내려받은 뒤 다시 동기화함 - 모바일폰과 각종 장치에서 SQLite처럼 임베디드 방식으로 구동함 - 기존 Turso 데이터베이스를 로컬 파일에 동기화하는 기능도 Turso/Postgres에서 지원할 계획임 - 단일 파일·임베디드 실행뿐 아니라 **와이어 프로토콜과 서버 구현**도 포함하므로 기존 애플리케이션, ORM, `psql`이 연결할 수 있음 - 가까운 시기에 Turso 팀이 직접 개발할 공식 프런트엔드는 SQLite와 Postgres이며, 다른 프런트엔드는 외부 기여자가 만들 수 있도록 구조를 개방함 ### 현재 실행 방법과 참여 - 아직 배포된 패키지는 없지만 소스에서 직접 빌드하고 실행할 수 있음 ```bash cd postgres/cli && cargo run ``` - Postgres 프런트엔드는 별도 저장소가 아니라 Turso 코드 트리 안에서 첫날부터 공식 프런트엔드로 개발됨 - 개발과 기여는 [Turso GitHub 저장소](https://github.com/tursodatabase/turso)에서 진행함 ### 호환성의 목표와 경계 - 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 라이선스**를 적용함 ## Comments ### Comment 61962 - Author: neo - Created: 2026-07-18T07:03:24+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/1clqwe/we_re_building_postgres_rust_using_llvm) - 거의 모든 SQL 데이터베이스가 쿼리를 **가상 머신(VM)** 용으로 컴파일하지 않나 싶음 이 점에서 SQLite만 특별히 꼽는 건 다소 이상해 보임 - 대부분의 데이터베이스는 **관계 연산 트리**를 만들고 각 연산에 푸시 또는 풀 인터페이스를 둠 반면 SQLite는 변수와 반복문이 있는 **명령형 바이트코드**로 쿼리를 컴파일함 - pgwire 개발자로서 Turso가 **PostgreSQL 호환 데이터베이스**에 pgwire를 다시 사용한다니 반가움 - 회사가 왜 **방향 전환**이 필요하다고 판단했는지 궁금함 - **SQLite 재구현**을 끝낸 건지, 아니면 포기한 건지 궁금함 https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next - https://github.com/tursodatabase/turso#how-compatible-is-turso-database-with-sqlite 여전히 그 목표를 유지하면서 중간에 다른 **프런트엔드**도 추가하는 것으로 보임 - 매우 흥미로운 글인데, 부당하게 **신고 처리**된 건 부끄러운 일임 - 언젠가 내 업무 프로젝트의 판도를 바꿀 수도 있을 만큼 **파급력이 큰 기술**임 결코 “off-topic”이나 “spam”이 아닌데 왜 그렇게 신고했는지 전혀 이해되지 않음 글에 대시가 하나 들어갔다고 AI 쓰레기로 단정한 건지도 모르겠고, 사람들이 정말 제정신을 잃어가는 느낌임 이 사이트의 신고 문화가 끔찍해졌으니 운영진이 조치했으면 함. 악의적으로 신고하는 몇 명을 차단하면 나머지도 자제할지 모름 - 이제 **부당한 신고** 자체가 이곳의 문화가 된 수준임 - 예전부터 Turso가 **SQLite의 계승자 행세**를 하는 태도에 거부감을 드러냈고, 그 때문에 몇 년 전부터 소프트웨어를 아예 써보지 않겠다고 다짐했음 하지만 SQL Server 밖에서도 빠르고 저렴한 **자동 갱신 구체화 뷰**를 제공한다면 결국 사용하게 될지도 모르겠음