본문으로 건너뛰기

3.3 개발 환경과 데이터 버전 제품

PR마다 데이터베이스를 하나씩 배정한다는 요구만으로는 제품을 고르기 어렵습니다. 새 schema에서 기능을 시험하려는지에 따라 필요한 기능이 달라집니다. 운영 데이터의 분포를 재현하거나 두 작업자가 수정한 데이터를 머지할 때도 마찬가지입니다. 접속 주소가 따로 생긴다는 공통점보다 생성 직후의 데이터를 먼저 비교해야 합니다. 변경 결과를 반영하는 방법도 함께 비교해야 합니다.

이 장의 비교 기준일은 2026-09-30입니다. PlanetScale의 두 엔진 제품과 Supabase의 두 생성 모드를 비교합니다. Prisma Postgres와 Composer, Dolt 계열, Turso의 두 세대도 비교합니다. 확인하지 못한 구현은 미확인으로 표시합니다. 기본값과 선택 옵션, 현재 제공 상태와 과거 발표를 구분합니다. 개발 환경 생성과 데이터 버전 관리의 차이를 실제 작업 순서에 연결합니다.

생성 데이터와 결과 반영의 비교​

제품과 모드생성 직후 데이터 범위생성 경로확인된 변경 기능 또는 단계
PlanetScale Vitess 기본 개발 branch부모 schema, 운영 데이터 제외schema 복제deploy request로 schema 배포
PlanetScale Postgres 기본 branch부모 schema와 data 제외빈 DB 생성Vitess deploy request 미지원
PlanetScale Postgres backup branchbackup의 schema와 databackup 복원부모와 지속 복제 미지원
Supabase 기본 branchschema, Edge Functions, 설정개발 환경 준비운영 데이터와 Storage object 제외
Supabase Include data데이터 포함, Auth와 Storage 세부 범위 미확인PITR add-on 필요, CoW 여부 미확인Dashboard 선택 옵션
Prisma Composer previewmigration으로 구성, 운영 데이터 제외stage별 별도 DBEarly Access, deploy action experimental
Dolt와 Doltgres데이터 버전branch와 commitdiff와 데이터 머지
Turso libSQL Cloud기존 DB 또는 지정 시점의 데이터Cloud branching과 PITR2023-09 기능 발표
Turso Database Cloud새 엔진의 Cloud 데이터 환경branching과 PITR, 공유 단위 미확인2026-04 private beta 발표

표의 행은 기본 경로를 중심으로 정리한 내용입니다. PlanetScale Vitess도 backup 복원과 별도 Data Branching 경로가 있습니다. 따라서 기본 개발 branch의 데이터 제외를 제품 전체의 제한으로 해석하지 않습니다. 여기서는 기본 경로를 비교합니다. 데이터 포함이 필요하면 선택한 옵션의 별도 문서를 확인하도록 범위를 제한합니다.

이 흐름은 검토 절차를 제안하는 도식입니다. 예를 들어 backup에서 복원한 환경이 있어도 schema 배포나 데이터 머지는 별도 단계입니다. 도입 요구서에는 환경 생성 API와 결과 반영 절차를 각각 적어야 합니다. 시험 성공 이후의 단계가 미정이면 preview 환경을 준비했어도 변경 관리 설계는 미완성입니다.

PlanetScale의 두 엔진 제품​

PlanetScale Vitess의 기본 개발 branch는 부모 schema를 복사한 별도 환경입니다. 운영 데이터는 기본으로 포함되지 않습니다. deploy request는 schema 변경을 검토하고 배포하는 절차입니다. Dolt의 일반적인 데이터 3-way 머지와는 기능 범위가 다릅니다. branch에서 수정한 업무 데이터를 운영으로 옮기려는 요구가 있을 수 있습니다. 이 요구는 schema 배포 절차와 분리해서 다뤄야 합니다.

PlanetScale Postgres의 일반적인 새 branch는 빈 DB입니다. 부모 schema와 data는 모두 제외됩니다. 반면 backup에서 만드는 branch는 schema와 data를 포함합니다. 두 모드를 모두 지원하므로 제품 이름만으로 데이터 포함 여부를 판정하기 어렵습니다. 예를 들어 개발자가 빈 branch를 요청했다면 별도 준비가 필요합니다. 애플리케이션의 migration과 시험 데이터 적재를 준비해야 합니다.

Postgres branch는 자체 스토리지를 가지며 부모와 지속 복제되지 않습니다. Vitess의 deploy request도 이 제품의 제공 범위에서 제외됩니다. 따라서 부모의 DDL이나 데이터 변경을 자식이 자동으로 따라간다는 전제를 두어서는 안 됩니다. 최신 데이터가 필요한 시험이라면 사용한 backup을 기록하는 편이 적절합니다. 환경 생성 후 얼마나 시간이 지났는지도 기록합니다.

role 관리 API가 branch 범위를 사용한다는 사실은 확인했습니다. 그러나 backup 복원의 전체 처리 규칙은 미확인입니다. 기존 role, extension, secret, scheduled job의 처리가 이에 해당합니다. DBA는 빈 branch와 backup branch를 나누어 검증하도록 제안합니다. 빈 DB의 초기 권한 설정에 성공했어도 복원 branch의 권한은 따로 검증해야 합니다.

이 제품군을 평가할 때는 동일 회사의 도구를 사용하는 편의와 엔진별 기능 범위를 구분합니다. Vitess에서 익숙한 검토 절차가 Postgres에서도 같다고 기대하면 운영 반영 설계가 빠집니다. 배포 설정에는 애플리케이션이 실제로 사용하는 엔진을 명시합니다. 선택한 branch 생성 방식도 명시하고, 그 조합에 맞는 migration 경로를 검토합니다.

Supabase의 선택 옵션과 Prisma Composer​

Supabase의 기본 branch는 schema, Edge Functions와 설정을 준비합니다. 운영 데이터와 Storage object는 포함하지 않습니다. 따라서 기본 모드는 작은 시험 데이터로 기능을 검증하는 요구와 먼저 대조합니다. 이 경로를 운영 데이터의 CoW 사본으로 소개하는 것은 부정확합니다. 데이터 분포와 크기가 필요한 시험은 초기 데이터 준비 조건부터 달라집니다.

Dashboard의 Include data는 PITR add-on이 필요한 선택 옵션입니다. 더 큰 디스크와 원본에 맞춘 compute 때문에 비용도 달라집니다. 데이터 포함 여부만으로 내부 공유 방식을 CoW로 분류할 수는 없습니다. 사실 대장에서 해당 구현은 미확인입니다. 기본 모드의 Storage object 제외 규칙은 적용 범위를 구분해야 합니다. 데이터 포함 옵션의 모든 Auth 및 Storage 동작은 별도로 확인해야 합니다.

Supabase branch에는 자체 API 자격증명이 있습니다. 한 branch에 설정한 secret은 다른 branch에서 자동으로 사용할 수 없습니다. 배포 workflow가 Vault secret이나 Function secret을 적용하는 동작이 있습니다. 이 동작은 단순 상속과 구분해서 읽어야 합니다. 새 branch의 public 기본 권한은 migration으로 명시적으로 부여해야 합니다. custom role, 모든 extension과 scheduled job의 처리는 별도 확인 대상입니다.

Git 연동 역시 생성 데이터의 범위와 다른 속성입니다. 2025년 Branching 2.0이 Git 없는 사용 방식을 도입했습니다. 2026년 5월에는 이를 기본 경험으로 전환했습니다. 이 변화만으로 데이터 포함 옵션까지 기본값이 되었다고 추론하지 않습니다. 현재 동작을 재현하려면 환경 생성의 진입 방식과 데이터 준비 옵션을 각각 기록해야 합니다.

Prisma의 2026년 9월 24일 공식 설명은 Prisma Postgres의 기능 범위를 명시합니다. CoW branching과 PITR는 제공 범위에 없습니다. Composer preview는 stage별 별도 DB를 migration으로 구성합니다. 운영 데이터는 복사하지 않습니다. 따라서 이전 비교에 등장한 1초 CoW branch라는 표현은 확정 기능에서 제외합니다. Composer는 Early Access입니다. 관련 cloud deploy action은 experimental이라는 제공 단계도 함께 기록합니다.

두 제품 모두 개발 흐름에 환경 준비를 연결하지만, 선택한 모드가 준비하는 내용은 다릅니다. 이 장에서는 같은 코드 변경을 적용한 뒤 필요한 schema와 데이터, 권한을 확인하도록 제안합니다. Composer stage의 전체 구성 규칙은 미확인입니다. role과 extension, secret, scheduled job이 확인 대상입니다. 따라서 migration 성공만으로 해당 항목의 준비를 완료 처리하지 않습니다.

Dolt 계열의 데이터 변경 관리​

Dolt 계열은 별도 환경 생성 외에도 데이터 버전과 차이를 다루는 기능 때문에 검토합니다. branch와 commit을 사용하고 데이터 diff와 머지를 수행합니다. 기존 Dolt와 Doltgres 실습은 실행 예를 제공합니다. 여기서는 다른 제품의 변경 기능과 구별되는 범위 및 현재 버전을 정리합니다.

Dolt의 머지는 cell 단위 변경을 고려합니다. 같은 행에서도 서로 다른 column을 수정하면 자동 머지가 가능한 경우가 있습니다. 동일 행 변경이 항상 충돌한다는 설명은 부정확합니다. 실제 검증에서는 같은 cell의 상이한 수정, 삭제와 수정을 별도 사례로 다뤄야 합니다. schema 및 제약조건 충돌도 별도 사례로 다뤄야 합니다. 자동 처리 가능성은 모든 데이터 충돌의 자동 해결을 뜻하지 않습니다.

Doltgres는 2026년 8월 6일 1.0을 출시했습니다. 공급사는 production 사용과 1.x의 안정된 형식을 표방합니다. 모든 PostgreSQL 기능 및 extension과 동일하다는 뜻은 아닙니다. SQLLogicTest 통과율은 발표 기준 약 560만 query에서 99% 이상입니다. 이 수치는 시험 집합의 통과율이며 전체 PostgreSQL 기능의 호환성과 구분해야 합니다.

공급사 문서의 Doltgres 1.0.0 sysbench 표는 PostgreSQL과 비교한 결과입니다. 읽기 평균 배수 2.3, 쓰기 3.4, 전체 2.7을 제시합니다. 각 시험의 median latency를 집계한 결과로, 적용 범위는 해당 시험에 한정됩니다. 이 장은 동일 환경의 대조 시험을 수행하지 않았습니다. 따라서 특정 배치나 운영 쿼리에 그 배수를 적용한 성능 예측은 보류합니다. 후보 검증에는 사용하는 SQL과 데이터 규모를 고정한 별도 측정이 필요합니다.

Dolt의 branch 권한은 인증된 SQL server 세션의 변경 작업을 통제합니다. 로컬 CLI 접근은 같은 방식으로 제한하지 않습니다. 따라서 데이터의 쓰기 분리와 접근 통제는 구분해서 다뤄야 합니다. Doltgres의 role, extension, secret과 job 버전 관리 범위도 개별 확인 대상입니다. 업무 데이터의 머지가 목적이라면 이 기능을 먼저 검증하도록 제안합니다. 애플리케이션의 호환성과 사용자 접근 경계도 함께 시험합니다.

Turso의 두 세대와 확인 범위​

기존 libSQL 기반 Turso Cloud는 2023년 9월 branching과 PITR를 발표했습니다. 기존 DB나 지정 timestamp에서 새 DB를 만드는 기능입니다. 이 기능을 branch 생성 후 지속 동기화나 데이터 머지로 설명하지 않습니다. 원본의 이후 변경을 계속 받아야 하는 요구는 분기 시점 선택과 별도로 검토해야 합니다.

새 Turso Database는 SQLite를 Rust로 재작성한 별도 엔진 계열입니다. 2026년 4월 새 엔진 기반 Cloud의 private beta 설명에도 branching과 PITR가 포함됩니다. 2026년 8월 동시 쓰기의 공개 early preview는 별도 발표입니다. 사용하려면 명시적으로 선택해야 합니다. 이 발표를 branching과 PITR의 GA 근거로 사용하지 않습니다.

두 세대의 정확한 공유 단위는 사실 대장에서 미확인입니다. 로컬 OSS 엔진만으로 Cloud branching을 재현하는 범위도 미확인입니다. token, secret과 job의 복제 정책도 각각 확인이 필요합니다. 따라서 이 장의 표에는 Cloud 기능의 존재와 발표 단계를 적었습니다. 세대별 내부 구현은 같은 CoW 방식으로 기재하지 않았습니다. 엔진 공개 여부와 관리형 기능의 자체 운영 여부를 구분해서 읽습니다.

후속 평가에서는 사용하려는 세대와 Cloud API를 고정하도록 제안합니다. 생성, 쓰기, 되돌리기, 정리를 하나의 시나리오로 시험합니다. 과거 고객 사례를 현재 엔진의 처리량이나 내부 구현의 증거로 소급하지 않습니다. 이 절차로 확보한 결과를 초기 데이터 범위와 변경 반영 방식에 연결합니다. 그러면 개발 환경 준비와 데이터 버전 관리 중 어느 요구를 충족했는지 구체적으로 기록할 수 있습니다.

참고​