4.2 온프레미스의 선택
사내 PostgreSQL 데이터를 외부로 보내지 않고 개발용 사본을 제공하려면 준비가 필요합니다. 저장 공간 외에도 담당자를 먼저 정해야 합니다. 원본 수집이 멈췄을 때 확인할 사람과 삭제가 실패했을 때 공간을 회수할 사람이 필요합니다. 같은 thin clone 요구라도 운영 범위는 다릅니다. DBA가 반복 시험을 수행하는 환경과 여러 팀에 데이터베이스를 제공하는 플랫폼을 구분해야 합니다.
이 장에서는 DBLab, ZFS 직접 구성, Xata OSS, Dolt 계열을 검토합니다. 보유 인프라와 호환성, 운영 인력을 기준으로 비교합니다. 비교 기준일은 2026-09-30이며 후보의 종합 순위를 제시하지 않습니다. 설치 명령과 개별 실습은 기존 온프레미스 대안에 둡니다. 여기서는 해당 접근을 선택할 조건과 파일럿의 합격 근거를 설명합니다.
보유 인프라와 결과 반영 방식
첫 질문은 시험이 끝난 뒤 무엇을 남길지입니다. 마이그레이션 파일과 검증 보고서만 운영에 전달한다면 PostgreSQL 사본 제공 경로부터 검토합니다. 데이터 변경을 diff로 검토하고 공통 조상 기준의 3-way 머지가 필요한 경우도 있습니다. 이때는 Dolt 계열의 호환성 시험을 먼저 진행합니다. 이 요구를 뒤늦게 추가하면 사본 생성만 검증한 파일럿으로는 결과 반영 절차를 평가하지 못합니다.
다음 표는 각 경로에서 다루는 구성과 상태를 비교합니다. 운영 인력이 몇 명이면 충분한지는 공개 기능표에서 산출하지 않습니다. 도입 조직은 현재 담당자가 관리하는 시스템과 새로 맡을 구성 요소를 대조해 담당 범위를 정합니다. 같은 Kubernetes를 사용하더라도 인증과 스토리지 운영이 기존 업무에 포함됐는지 확인합니다.
| 경로 | 기반 구성 | 분기 또는 버전 기준 | 별도 확인 대상 |
|---|---|---|---|
| ZFS 직접 구성 | PostgreSQL, ZFS dataset | origin snapshot | 전체 cluster의 snapshot 범위 |
| DBLab | 수집 환경, PostgreSQL 이미지, clone | 자동 snapshot, 명명된 branch | major version, extension 바이너리 |
| Xata OSS | Kubernetes, CloudNativePG, OpenEBS | 스토리지 snapshot과 clone 경로 | StorageClass, CSI, fallback |
| Dolt 계열 | 데이터 버전 관리 엔진 | commit과 공통 조상 | SQL 호환성, 머지 충돌 |
표의 마지막 열은 특정 버전과 배치에서 확인할 조건입니다. 미지원 기능 목록으로 해석하지 않으며, 미확인 항목은 그대로 유지합니다. 일회성 작업이라면 새로운 플랫폼의 설치와 유지 비용까지 포함합니다. 이 비용을 기존 backup 및 restore 절차와 비교합니다. 반복 요청이 많다는 이유만으로 도입을 결정하는 대신 담당자의 작업도 검증합니다. 요청부터 정리까지 담당자가 수행할 작업을 파일럿에 포함합니다.
DBLab의 반복 시험 경로
DBA 팀이 같은 원본으로 쿼리와 마이그레이션 시험을 반복한다면 DBLab을 우선 검증할 후보로 둡니다. GitLab의 공식 개발 문서는 DBLab을 운영 규모 데이터의 검증에 사용한다고 설명합니다. 사례 신뢰도는 높음입니다. 이 근거는 검증 용도로 사용한다는 사실을 확인합니다. 모든 CI 작업에 같은 방식을 적용한다는 증거로 확대하지 않습니다. 다른 제품보다 복구 성능이 높다는 주장도 별도 근거가 필요합니다.
DBLab 4.0은 snapshot을 가리키는 명명된 branch를 도입했습니다. 사용자 요청 snapshot도 도입했습니다. 이전부터 자동 snapshot도 생성했으므로 사용자가 commit한 시점만 남는다고 설명하지 않습니다. 선택할 때는 보존할 기준점과 접속할 clone을 구분합니다. 이름 있는 branch의 생성 응답과 PostgreSQL 접속 및 시험 준비 완료 확인은 구분합니다. 두 확인 결과를 별도 기록으로 남기도록 제안합니다.
호환성 검증에는 원본의 PostgreSQL major version에 맞는 이미지 선택을 포함합니다. 필요한 extension 바이너리도 준비해야 합니다. PostgreSQL을 실행한다는 사실을 모든 버전과 확장에 제약이 없다는 뜻으로 바꾸지 않습니다. 원본 role, secret, scheduled job, pg_hba.conf의 처리 방식도 확인합니다. physical 및 logical 수집 모드별로 확인합니다. 생성 시 지정하는 clone 자격증명과 원본 인증 정보의 복제 범위는 별개입니다. 원본의 모든 인증 정보가 동일하게 복제되는지는 따로 확인합니다.
수집 담당자와 시험 환경 담당자의 책임을 작업 기록에서 구분하도록 제안합니다. 수집 담당자는 마지막으로 준비된 데이터 시점과 갱신 실패를 관리합니다. 시험 환경 담당자는 접속 정보와 동시 사용량, 만료 처리를 관리합니다. 오래된 기준 사본으로도 시험 자체가 성공하는 상황을 실패 가설에 넣습니다. 결과 보고서에 기준 시점을 표시합니다. 허용한 최신성 범위를 벗어나면 결과 승인을 보류하도록 설계합니다.
DBLab의 설치, branch 명령, clone 사용 절차는 DBLab Engine 상세에 연결합니다. 이 장의 파일럿에서는 자동화 성공 횟수 외에 갱신 실패 후 재개와 중단된 시험의 정리를 확인합니다. 4.2의 pg_upgrade --link 경로처럼 버전에 따라 작업이 달라지는 항목이 있습니다. 이런 항목은 해당 버전의 절차로 시험합니다. 업그레이드가 항상 전체 데이터를 다시 쓴다고 일반화하지 않습니다.
ZFS 직접 구성의 책임 범위
이미 ZFS를 운영한다면 직접 구성을 비교합니다. PostgreSQL 사본 기동과 정리를 자체 자동화할 인력이 있다는 조건도 필요합니다. ZFS clone은 snapshot에서 만드는 쓰기 가능한 dataset이며 origin snapshot에 의존합니다. 초기 block을 공유하고 보존된 참조가 있는 이전 block을 유지합니다. 따라서 clone 생성 직후의 작은 추가 사용량을 장기간 유지 비용으로 환산하지 않습니다.
실행 중 PostgreSQL의 snapshot에는 전체 cluster의 일관된 시점이 필요합니다. 필요한 WAL과 tablespace도 같은 시점에 맞춰야 합니다. PGDATA만 복사하는 절차를 모든 배치에 적용하지 않습니다. 직접 구성의 도입을 검토할 때는 파일 배치를 먼저 조사하도록 제안합니다. snapshot 대상과 복구에 필요한 파일의 대응 관계도 문서화합니다. 볼륨 생성이 성공했더라도 PostgreSQL 기동과 데이터 검증이 실패하면 해당 절차를 미완료로 기록합니다.
파일 복제 범위에 관한 사실 대장의 추론도 구분합니다. dataset 밖의 extension 바이너리와 secret 파일은 자동 포함되지 않는다는 설명입니다. OS scheduler와 외부 서비스도 여기에 해당합니다. 이는 배치 범위에서 도출한 유력 판단입니다. 실제 구성에서는 파일 위치와 실행 주체를 확인해야 합니다. 복제에서 누락되는 항목과 복제 후 외부 운영 자원에 접근하는 항목을 각각 검사하도록 제안합니다.
직접 구성에서는 snapshot 생성 이후의 접속 설정, 권한, 삭제 순서도 운영 절차로 작성합니다. 같은 pool 안의 clone을 독립적인 장애 복구용 백업으로 취급하지 않습니다. 원본 갱신 후 저장량 증가와 origin 참조가 남은 상태의 정리 실패를 시험에 포함합니다. 담당자는 snapshot 삭제 요청 기록에 더해 참조 관계와 회수 결과까지 확인하도록 설계합니다.
구체적인 명령과 PostgreSQL 기동 순서는 ZFS Snapshot과 Clone에서 다룹니다. 직접 구성과 DBLab을 비교할 때는 같은 원본과 수명 조건을 적용합니다. 이미 작성한 자동화의 유지보수 시간이 적다면 직접 구성이 검토 대상에 남습니다. 수집부터 정리까지 반복해서 누락되는 작업이 많다면 DBLab 파일럿에서 해당 작업의 처리 범위를 확인합니다.
Xata OSS의 플랫폼 운영 범위
Kubernetes에서 다수의 PostgreSQL 환경을 제공하려는 팀은 Xata OSS를 후보로 검토합니다. 공개 구성은 CloudNativePG와 OpenEBS의 로컬 또는 Mayastor 경로를 사용합니다. Xatastor는 포함하지 않습니다. 상용 Xatastor의 compute 측은 XFS와 NVMe-oF 구조로 설명됩니다. storage 측은 ZFS zvol 구조입니다. 상용 스토리지의 성능과 복제 동작을 OSS 설치 결과에 적용하려면 별도 검증이 필요합니다.
각 로컬 StorageClass가 실제 CoW를 수행하는지는 사실 대장에서 미확인입니다. 전체 복사로 fallback하는지도 미확인입니다. 따라서 파일럿은 저장소 버전과 StorageClass, CSI 드라이버를 고정해 수행하도록 제안합니다. branch 요청부터 snapshot과 PVC clone의 처리 경로를 확인합니다. 데이터 규모를 바꾸어 SQL 준비 시간도 측정합니다. 문서에 없는 fallback 사례를 이미 발생한 장애처럼 서술하지 않습니다.
운영 인력은 PostgreSQL과 스토리지 외에 담당할 범위를 검토합니다. control plane, gateway, 인증 구성도 검토 대상에 포함합니다. CloudNativePG 운영 경험이 입증하는 범위는 일부 구성에 한정합니다. 파일럿에서는 생성 도중 제어 구성 요소가 중단되는 상황을 넣습니다. 재개 뒤 남은 리소스와 접속 상태를 확인하도록 제안합니다. 이 시험 절차는 공급사의 자동 복구 보장을 설명하는 문장이 아닙니다.
공개 핵심 구성 요소의 라이선스는 Apache 2.0입니다. 공급사는 적대적 멀티테넌시 보호가 빠진 OSS를 공개 PaaS에 사용하는 것을 권장하지 않습니다. 이는 기술과 운영 범위의 제한입니다. 외부 고객 제공에 특정 상용 옵션 구매가 법적으로 필수인지는 이 제한과 구분해야 합니다. 내부 사용이라도 사용자 사이의 권한과 외부 연결을 별도로 확인합니다. 확인하지 않은 격리 수준은 미확인으로 기록합니다.
구성 요소와 설치 흐름은 Xata OSS와 Kubernetes에 연결합니다. 도입 문서에는 PostgreSQL 이미지뿐 아니라 공개 플랫폼과 스토리지 버전도 기록하도록 제안합니다. 이후 갱신한 구성 요소에 따라 생성 경로와 장애 복구 시험의 재실행 범위를 정합니다. 해당 조합의 유지 담당자가 정해지지 않았다면 다수 팀으로 제공 범위를 늘리는 결정을 보류합니다.
Dolt 계열의 호환성과 변경 검토
데이터 diff와 3-way 머지가 요구사항이라면 Dolt 계열을 먼저 검증합니다. Dolt는 공통 조상과 두 변경을 비교하며 cell 단위 변경을 고려합니다. 같은 행의 서로 다른 column 변경은 자동 머지되는 경우가 있습니다. 따라서 같은 행을 바꾸면 항상 충돌한다고 가정하지 않습니다. 같은 cell의 상이한 변경과 제약조건 충돌을 구분해 재현하도록 제안합니다.
Doltgres는 2026년 8월 6일에 1.0을 출시했습니다. 현재 상태는 베타가 아닌 1.0 출시로 기록합니다. 모든 PostgreSQL 기능과 extension의 동등성은 별도 검증 대상입니다. 공급자의 SQLLogicTest 통과율과 특정 sysbench 결과는 시험 범위에 한정해 해석합니다. 이를 조직의 애플리케이션 호환성이나 보편적인 성능 배수로 환산하지 않습니다. 사용 중인 SQL, 트랜잭션, 필요한 확장을 대상으로 파일럿을 구성합니다.
온프레미스에서의 첫 적용 범위는 변경 검토가 필요한 데이터 집합부터 정하도록 제안합니다. 예를 들어 참조 데이터의 변경을 리뷰하려는 요구라면 해당 테이블의 반입과 반출을 시험합니다. 충돌 해소와 승인 후 반영까지 시험에 포함합니다. 운영 PostgreSQL 전체를 바꾸는 결정에는 별도 호환성 검증이 필요합니다. SQL 접속 성공만으로 현재 애플리케이션을 옮길 준비가 끝났다고 판단하지 않습니다.
Dolt의 branch 권한은 인증된 SQL server 세션의 변경 작업을 통제합니다. 로컬 CLI 접근을 같은 방식으로 제한하지 않습니다. 따라서 데이터 머지 권한과 서버 파일 접근 권한을 따로 설계합니다. Doltgres의 role, extension, secret, job의 버전 관리 범위는 별도 확인 대상으로 남깁니다. Dolt와 Doltgres 실습에서는 명령과 변경 이력 확인을 다룹니다.
최종 선택 기록에는 원본 수집, 사용자 격리, 기준 데이터 갱신의 담당자를 남기도록 제안합니다. 만료 삭제와 장애 복구의 담당자도 기록합니다. 후보별로 확보한 시험 증거와 미확인 항목을 함께 보관합니다. 보유 인프라가 달라지거나 담당 팀이 바뀌면 이 기록으로 도입 범위를 다시 검토합니다. 특정 도구의 설치 성공을 전체 운영 절차의 검증 완료로 처리하지 않습니다.