Turso Postgres 호환 DB 2026, Rust 데이터 플랫폼 도입 전 성능·비용 기준

Turso Postgres 호환 DB 검토를 위한 Rust 데이터베이스 아키텍처 리뷰 장면 — Turso/Postgres 검토의 핵심은 Rust라는 언어보다 호환성 경계와 운영 책임을 먼저 고정하는 것이다.

Turso Postgres 호환 DB 소식은 단순한 “Postgres를 Rust로 다시 쓴다”는 문장으로 읽으면 판단이 흐려진다.

운영팀이 봐야 할 핵심은 Rust 구현 자체가 아니라 Turso 코어 위에 Postgres 프런트엔드를 얹는 구조가 어떤 워크로드에 맞는지다.

Turso 공식 글은 SQLite가 첫 프런트엔드였고 Postgres가 다음 프런트엔드가 된다고 설명한다.

같은 글은 Postgres SQL을 공통 AST로 파싱하고 Turso bytecode로 컴파일해 실행하는 방향을 제시한다.

그래서 이 글은 Turso Postgres 호환 DB를 데이터 플랫폼 후보로 볼 때의 성능, 비용, 보안, 운영 기준을 정리한다.

핵심 요약

Turso/Postgres는 완성된 운영 DB보다 Postgres 호환 프런트엔드를 Turso 코어에 붙이는 개발 기반으로 보는 편이 안전하다.
검색 의도는 “Rust라서 빠른가”보다 psql, ORM, wire protocol, extension, migration이 어디까지 맞는지에 있다.
임베디드 Postgres, 브라우저 실행, agent별 단일 파일 DB 같은 시나리오는 흥미롭지만 데이터 보호와 복구 기준이 먼저다.
도입 판단은 실험실 합성 데이터, 호환성 리포트, rollback 경로, DBA 승인자를 갖춘 뒤 단계적으로 해야 한다.

이 글이 필요한 사람

Turso Postgres 호환 DB 소식을 보고 데이터 플랫폼 실험 후보인지 판단하려는 플랫폼 리드
Postgres 호환성을 유지하면서 임베디드 또는 로컬 우선 데이터베이스를 검토하는 백엔드 개발자
Rust 데이터베이스 프로젝트의 성능 기대와 운영 리스크를 분리해서 보고 싶은 CTO
psql, ORM, extension, migration, backup이 실제로 어디까지 맞는지 점검해야 하는 DBA
AI agent마다 격리된 데이터베이스를 만들거나 브라우저 안 DB를 실험하려는 DevOps 담당자

Turso 발표를 기존 Postgres Rust 재작성과 다르게 읽는다

이미 Postgres Rust 재작성 프로젝트는 pgrust처럼 다른 방향에서도 나오고 있다.

pgrust 계열은 기존 Postgres 동작을 Rust로 재현하는 호환성 실험에 가깝다.

Turso 발표의 차이는 기존 Postgres를 줄 단위로 옮기는 것보다 하나의 데이터베이스 코어에 여러 프런트엔드를 붙이는 설계에 있다.

Turso는 이 구조를 데이터베이스의 LLVM이라고 표현한다.

이 비유를 그대로 믿기보다 SQL 언어, AST, bytecode, storage, protocol, extension 경계가 실제로 분리되는지 검증해야 한다.

따라서 기존 pgrust 글과 겹치지 않게 Turso/Postgres는 임베디드 실행과 다중 프런트엔드 데이터 플랫폼 관점으로 보는 편이 맞다.

아키텍처 핵심: Postgres 언어를 Turso 코어로 컴파일한다

Turso 공식 글은 SQLite가 SQL을 VDBE bytecode로 컴파일해 실행한다는 내부 구조를 설명한다.

SQLite 공식 문서도 VDBE가 SQL 명령을 실행하기 위한 bytecode engine이라고 설명한다.

Turso는 이 아이디어를 가져와 SQLite 방언뿐 아니라 Postgres 언어도 공통 실행 코어로 낮추려는 방향을 잡았다.

초기 가능성 검증은 pgmicro에서 진행됐고, 이후 Turso main tree에 병합된 공식 프로젝트로 전환됐다고 발표했다.

이 구조가 맞다면 데이터 플랫폼 입장에서는 SQL frontend와 실행 core, 저장 구조, wire protocol을 따로 평가해야 한다.

평가 층	Turso/Postgres에서 볼 것	실무 질문	보류 신호
SQL frontend	Postgres SQL을 AST로 파싱하는 범위	조직 쿼리와 migration SQL이 파싱되는가	DDL, window function, JSON, CTE에서 gap이 크다
Execution core	Turso VDBE와 확장 opcode의 표현력	대표 쿼리가 결과와 성능 모두 안정적인가	결과 diff 또는 planner gap을 설명하지 못한다
Storage	SQLite 파일 호환성과 Turso 확장 기능의 경계	단일 파일과 sync 모델이 복구 목표에 맞는가	backup restore와 corruption 대응 문서가 없다
Protocol	Postgres wire protocol과 서버 구현	psql, ORM, pooler가 연결되는가	접속만 되고 transaction 동작 검증이 없다
Extension	WASM 기반 extension 가능성	필수 extension이 대체 가능한가	PostGIS, pgvector, PL 계열 의존이 크다

이 표에서 가장 먼저 닫을 항목은 SQL frontend와 protocol이다.

psql이 연결된다는 말은 시작점일 뿐이며, transaction isolation, prepared statement, type mapping, error code까지 확인해야 한다.

현재 성숙도: 실행 가능한 foundation이지 drop-in replacement는 아니다

Turso 공식 글은 현재 결과물을 finished product가 아니라 real running foundation이라고 표현한다.

또한 배포된 패키지는 없지만 source에서 직접 build하고 run할 수 있다고 안내한다.

공식 글에 나온 현재 실행 흐름은 postgres/cli 디렉터리에서 cargo run을 실행하는 개발 기반 확인에 가깝다.

이 단계의 프로젝트를 운영 DB 교체 후보로 바로 올리면 위험하다.

운영 평가에서는 기능이 “있다”보다 어떤 버전의 어떤 commit에서 어떤 테스트가 통과했는지 기록해야 한다.

특히 Postgres 호환 DB는 SQL 결과뿐 아니라 error behavior, lock, vacuum, WAL, backup, extension, client protocol이 함께 맞아야 한다.

성능 기준: Rust 구현보다 workload fit을 먼저 본다

Rust로 작성됐다는 사실만으로 데이터베이스 성능이 자동으로 좋아지는 것은 아니다.

데이터베이스 성능은 parser 언어보다 storage layout, concurrency control, planner, cache, IO path, workload 분포에 더 크게 좌우된다.

Turso는 MVCC 기반 concurrent writes, asynchronous execution, live materialized views 같은 특징을 강조한다.

이 기능은 브라우저, 모바일, 단일 파일, local-first 앱처럼 기존 Postgres 서버가 무거운 환경에서 검토 가치가 있다.

반대로 대형 OLTP 운영 DB를 그대로 바꾸는 목적이라면 현재 단계에서는 성능 비교보다 호환성 gap이 더 큰 리스크다.

워크로드	검토 가치	성능 확인 항목	운영 판단
브라우저 또는 모바일 임베디드 DB	서버 없이 Postgres 유사 SQL을 실험할 수 있음	초기 load time, memory, persistence, sync 비용	합성 데이터와 offline 시나리오부터 검증
AI agent별 격리 DB	사용자별 단일 파일 DB를 빠르게 만들 수 있음	파일 생성 비용, cleanup, quota, sandbox	agent 권한과 데이터 삭제 정책이 먼저
개발자 테스트 DB	로컬에서 psql 또는 ORM smoke test 후보	schema migration, seed data, transaction	CI에서 reproducible한지 확인
운영 Postgres 대체	현시점에서는 장기 관찰 대상	extension, backup, replication, monitoring	운영 교체 후보로는 보류

이 조건이면 Turso/Postgres 실험은 의미가 있다.

운영 DB를 줄이는 목적이 아니라 edge, browser, local-first, agent sandbox 같은 새로운 실행 형태를 검증하는 경우다.

이 경우도 대표 쿼리 20개, migration 5개, ORM 초기화 2개를 먼저 정하고 결과 diff를 남기는 편이 안전하다.

비용 기준: 도구 비용보다 검증 비용이 먼저 나온다

Turso repository는 MIT 라이선스로 공개되어 있지만 무료 오픈소스라는 사실만으로 실험 비용이 0이 되지는 않는다.

실제 비용은 DBA 검토 시간, compatibility test 작성, CI 격리 환경, 문서화, 장애 대응 기준 수립에서 발생한다.

프로덕션 교체가 아니라 실험이라도 비용 owner가 없으면 결과가 흩어진다.

Rust 데이터베이스 후보를 평가할 때는 “얼마나 빠른가”보다 “어떤 gap을 닫으려면 며칠이 드는가”가 더 현실적인 비용이다.

PGlite처럼 브라우저 또는 Node.js 안에서 Postgres 계열 실행을 제공하는 대안도 있으므로 임베디드 목적만으로 Turso를 단정하면 안 된다.

비교 대상이 있다면 같은 schema, 같은 쿼리, 같은 persistence 조건으로 테스트해야 한다.

보안 기준: 단일 파일 DB와 agent sandbox를 분리한다

Turso 공식 글은 agent가 사용자마다 새 Postgres database를 만들고 각각을 하나의 file로 관리하는 그림을 제시한다.

이 시나리오는 AI agent와 로컬 우선 앱에는 매력적이지만 보안팀 관점에서는 파일 수명주기와 접근권한이 핵심이다.

단일 파일 DB는 배포가 쉽지만 복사, 업로드, 백업, 삭제, 암호화 경계가 동시에 중요해진다.

브라우저 안에서 실행되는 DB는 origin isolation, storage quota, local cache, 로그 유출을 별도로 확인해야 한다.

WASM extension 방향도 흥미롭지만 arbitrary extension 실행을 제한하려는 설계 판단이 아직 최종 확정은 아니다.

보안 승인은 extension을 얼마나 많이 지원하는지가 아니라 extension이 어떤 권한으로 실행되고 어떻게 차단되는지로 봐야 한다.

운영 기준: Postgres 호환성은 “연결됨”으로 끝나지 않는다

PostgreSQL 공식 protocol 문서는 frontend와 backend가 메시지를 주고받는 wire protocol 구조를 설명한다.

Turso 공식 FAQ도 기존 applications, ORMs, psql이 연결할 수 있도록 wire protocol과 server implementation을 포함한다고 말한다.

그러나 실무 호환성은 접속 성공보다 더 넓다.

connection pooler, prepared statement, error code, transaction isolation, migration tool, logical type mapping을 확인해야 한다.

ORM은 간단한 select보다 schema introspection과 migration 단계에서 더 자주 깨진다.

운영팀은 “psql 연결 성공”을 green light로 보지 말고 compatibility report의 첫 줄로만 처리해야 한다.

실무 시나리오 1: local-first SaaS의 데이터 플랫폼 실험

B2B SaaS가 오프라인 편집 기능을 넣으려면 로컬 저장소와 서버 동기화를 같이 설계해야 한다.

이 조건이면 Turso/Postgres의 단일 파일, sync, Postgres 유사 SQL 방향은 실험할 가치가 있다.

다만 고객 데이터가 로컬 파일에 남기 때문에 암호화, 삭제 요청, 기기 분실, audit log 기준이 먼저 정해져야 한다.

개발팀은 실제 고객 DB가 아니라 익명화 schema와 합성 데이터로 ORM startup과 migration dry-run만 확인한다.

보안팀은 local file path, backup inclusion, crash dump, browser storage 정책을 승인 항목으로 둔다.

실무 시나리오 2: AI agent별 격리 DB를 만드는 경우

AI agent가 사용자마다 독립적인 임시 데이터베이스를 갖는 구조는 권한 분리와 cleanup에 장점이 있다.

Turso가 말하는 agent별 file database 그림은 이 방향과 잘 맞는다.

이 경우는 성능보다 quota, TTL, prompt에 들어가는 schema 정보, 파일 삭제 증적이 더 중요하다.

agent가 만든 DB 파일을 운영 계정이 직접 읽거나 외부 storage로 복사할 수 있으면 격리 효과가 약해진다.

플랫폼팀은 per-user database 생성과 삭제를 audit event로 남기고, 장애 시 어떤 파일을 복구하지 않을지도 정해야 한다.

실무 시나리오 3: 개발자 테스트 DB를 가볍게 만들고 싶은 경우

개발자 노트북에서 Postgres 호환 테스트 DB를 빠르게 띄우는 목적은 운영 교체보다 현실적인 초기 실험이다.

이 조건이면 psql, ORM, migration tool, seed script가 어떤 단계에서 실패하는지 보는 smoke test가 충분하다.

단순 CRUD는 통과해도 constraint, transaction rollback, JSON operator, extension dependency에서 차이가 날 수 있다.

따라서 “테스트 통과”라는 결론은 기능별 matrix로 남겨야 한다.

CI에 붙일 때는 cache와 build time이 비용으로 바뀌므로 commit hash와 binary artifact를 고정해야 한다.

도입 전 비교표: Turso/Postgres, pgrust, 표준 Postgres, PGlite

선택지	강점	맞는 상황	주의할 점
Turso/Postgres	Turso 코어에 Postgres frontend를 붙이는 장기 구조	embedded, browser, agent sandbox, local-first 실험	foundation 단계라 compatibility gap을 닫아야 함
pgrust 계열	Postgres 동작 재현과 회귀 테스트 중심	Rust 기반 Postgres 호환성 실험 비교	운영 DB 대체 후보로 단정하면 위험함
표준 PostgreSQL	성숙한 extension, backup, replication, 운영 생태계	현재 운영 시스템과 critical workload	임베디드 또는 브라우저 실행에는 무거울 수 있음
PGlite	WASM 기반 Postgres 계열 local 실행 경험	브라우저, 테스트, client-side prototype	운영 Postgres 전체를 대체한다는 뜻은 아님

이 비교에서 Turso/Postgres는 “기존 Postgres를 당장 바꿀 후보”보다 “새 실행 형태를 검증할 후보”에 가깝다.

표준 Postgres는 여전히 운영 기준점이고, Turso/Postgres는 그 기준점과 얼마나 다르게 움직이는지 측정해야 한다.

실무 스켈레톤: 평가 정책 YAML

아래 YAML은 Turso Postgres 호환 DB 실험을 운영 DB 교체 논의와 분리하기 위한 정책 뼈대다.

# turso-postgres-evaluation.yaml
# 목적: Turso Postgres 호환 DB를 데이터 플랫폼 후보로 볼 때 검증 범위를 고정한다.
# 실제 배포 기준, 데이터 등급, 승인자는 조직의 표준에 맞게 바꾼다.

candidate:
  name: turso-postgres
  maturity: foundation-source-build
  production_use: blocked_until_compatibility_report
  source_of_truth:
    - official_turso_blog
    - turso_github_repository
    - postgresql_protocol_docs

allowed_lab_scope:
  data:
    synthetic_only: true
    customer_data_allowed: false
  network:
    production_network_allowed: false
    public_package_mirror_allowed: reviewed
  workload:
    read_only_sql: allowed
    orm_smoke_test: allowed
    write_benchmark: allowed_on_synthetic_data
    migration_replay: staging_copy_only

compatibility_gate:
  must_pass:
    - psql_connection_smoke_test
    - orm_startup_test
    - schema_migration_dry_run
    - representative_query_result_diff
    - extension_inventory_check
  must_document:
    - unsupported_sql_features
    - extension_gap
    - backup_restore_gap
    - observability_gap

release_decision:
  approve_experiment_if:
    - no_customer_data
    - clear_rollback_path
    - compatibility_gap_is_listed
  reject_if:
    - team_expects_full_postgres_replacement
    - extension_dependency_is_critical
    - no_dba_review_owner

핵심은 합성 데이터, 격리 네트워크, compatibility report, 승인자를 먼저 고정하는 것이다.

이 기준 없이 Rust 데이터베이스 실험을 열면 “재미있는 데모”와 “운영 후보”가 같은 문서에 섞인다.

소스 빌드 확인 예시

공식 글은 아직 published package가 없고 source에서 build하고 run할 수 있다고 말한다.

아래 스크립트는 개발 기반 확인용이며, 실제 실행 옵션은 Turso repository의 최신 README를 다시 확인해야 한다.

#!/usr/bin/env bash
# turso-postgres-smoke-test.sh
# 목적: 공식 발표에 나온 source build 흐름을 실험실에서만 확인한다.
# 실제 저장소 경로와 실행 명령은 Turso 공식 README의 현재 상태를 다시 확인한다.

set -euo pipefail

WORKDIR="${WORKDIR:-$HOME/lab/turso-postgres}"
RESULT_DIR="${RESULT_DIR:-$PWD/turso-postgres-results}"
mkdir -p "$RESULT_DIR"

if [ ! -d "$WORKDIR/.git" ]; then
  git clone https://github.com/tursodatabase/turso "$WORKDIR"
fi

cd "$WORKDIR"
git rev-parse HEAD | tee "$RESULT_DIR/turso-commit.txt"

# 공식 블로그가 언급한 개발 기반 확인용 명령이다.
# 패키지 배포 전 단계이므로 실패 로그도 결과로 남긴다.
cd postgres/cli
cargo run -- --help > "$RESULT_DIR/cli-help.txt" 2>&1 || true

# 실제 Postgres wire protocol 검증은 서버 구현과 실행 옵션이 문서화된 뒤 붙인다.
# psql, ORM, migration tool 테스트는 여기서 별도 단계로 분리한다.
echo "next: psql smoke, ORM startup, schema migration dry-run" | tee "$RESULT_DIR/next-steps.txt"

이 단계에서 얻어야 할 결과는 production readiness가 아니라 commit, build log, 실패 지점, 다음 검증 항목이다.

서버 옵션과 protocol surface가 명확해진 뒤에 psql과 ORM test를 붙이는 편이 안전하다.

호환성 gap 리포트 예시

데이터 플랫폼 후보를 검토할 때는 성공한 데모보다 실패한 항목을 더 잘 남겨야 한다.

#!/usr/bin/env python3
# compatibility_gap_report.py
# 목적: Turso/Postgres 실험 결과를 운영 승인 전에 같은 형식으로 정리한다.
# 실제 쿼리 결과 비교와 extension 목록은 조직의 테스트 데이터로 채운다.

from dataclasses import dataclass, asdict
import json

@dataclass
class Check:
    name: str
    status: str
    evidence: str
    risk: str
    owner: str

checks = [
    Check("psql wire protocol", "pending", "server option not fixed in this lab", "client compatibility unknown", "platform"),
    Check("ORM startup", "pending", "representative app not connected", "runtime mismatch", "backend"),
    Check("extensions", "blocked", "WASM extension direction is not final", "critical extension may not load", "dba"),
    Check("backup restore", "pending", "single-file and sync path need current docs", "recovery objective unclear", "sre"),
    Check("observability", "pending", "metrics/log surface not evaluated", "incident triage delay", "sre"),
]

summary = {
    "candidate": "turso-postgres",
    "decision": "lab-only",
    "reason": "foundation is interesting, but production compatibility gates are not closed",
    "checks": [asdict(item) for item in checks],
}
print(json.dumps(summary, ensure_ascii=False, indent=2))

이 리포트가 pending과 blocked를 숨기지 않아야 의사결정자가 실험 범위를 오해하지 않는다.

특히 extension과 backup restore는 Postgres 호환 DB 평가에서 마지막까지 남는 비용 항목이다.

CI 게이트 예시

실험 문서가 운영 도입 문구로 부풀려지는 것을 막으려면 PR 단계에서 표현과 격리 기준을 검사할 수 있다.

name: turso-postgres-lab-gate
on:
  pull_request:
    paths:
      - database-lab/**
      - docs/turso-postgres-evaluation.md

jobs:
  compatibility-report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Require evaluation policy
        run: test -s database-lab/turso-postgres-evaluation.yaml
      - name: Generate compatibility gap report
        run: python database-lab/compatibility_gap_report.py > gap-report.json
      - name: Block production wording
        run: |
          ! grep -R "production-ready\|drop-in replacement\|full Postgres replacement" docs database-lab
      - name: Keep experiment isolated
        run: |
          grep -R "synthetic_only: true" database-lab/turso-postgres-evaluation.yaml

이 workflow는 실제 DB 품질을 보장하지 않는다.

대신 production-ready 같은 단정 표현을 막고 합성 데이터 격리 기준을 문서에 남기는 안전장치다.