기다릴 수 없거나 PG18의 완전한 인스턴스 격리가 필요한 사람들을 위해, 나는 ZFS 스냅샷을 이용해 즉시 브랜칭하는 도구 Velo를 만들었음
어떤 PostgreSQL 버전에서도 작동하며, 각 브랜치는 독립된 컨테이너와 포트를 가짐
100GB DB 기준 약 2~5초면 생성 가능함
PG18 방식과의 차이는, 단일 인스턴스를 공유하지 않고 완전한 서버 격리를 제공한다는 점임 GitHub 링크
다른 댓글에서 Claude Code 사용에 대한 불만이 있었지만, GitHub 페이지의 데모 영상을 보고 흥미롭게 느꼈음
요즘 대부분의 소프트웨어가 AI 에이전트의 도움을 받아 작성되는데, 왜 불평이 나오는지 모르겠음. 접근 방식이 흥미로움
나도 비슷한 걸 btrfs로 프로토타입 해보려던 참이었음
“너”라는 표현이 흥미롭다고 생각했는데, 표절했다는 말이 있어서 좀 놀랐음
예전에 회사가 RDS로 마이그레이션할 때 비슷한 시스템을 직접 구축했음
프로덕션 마이그레이션 중 자주 문제가 생겨서, 이를 방지하기 위해 다음 단계를 자동화했음
RDS DB를 복제하거나 백업에서 새 인스턴스를 생성
ARN으로부터 CNAME 또는 퍼블릭 IP 추출
앱의 DB 연결 설정에 반영
가짜 프로덕션 환경에서 마이그레이션 실행
이 과정 덕분에 로컬이나 CI에서는 잡히지 않던 프로덕션 특유의 버그를 많이 잡을 수 있었음
이후 간단한 Ruby 스크립트로 자동화했고, 아직도 그 스크립트를 사용 중이라고 들었음
나도 그런 “데이터 특이성 때문에 프로덕션에서만 실패하는 마이그레이션” 버그를 정말 싫어함. 몇 번은 그 때문에 릴리스를 취소한 적도 있음
템플릿 클로닝 전략이 설정 가능하다는 걸 이번에 처음 알았음
나는 Neon을 이용해 실시간 통합 환경을 만들었고, 내 Golang 프로젝트 pgtestdb 에서는 각 테스트마다 완전한 스키마 마이그레이션이 적용된 Postgres DB를 생성함
예전에 스타트업에서 btrfs로 즉시 스테이징 DB를 만드는 걸 본 적 있는데, 비슷한 아이디어가 반복 등장하는 게 흥미로움
이런 빠른 복제와 테스트는 Postgres와 Sqlite의 큰 장점이며, Clickhouse나 MySQL에서도 가능했으면 좋겠음
요즘 PostgreSQL이 거의 모든 SQL 용도를 커버하는 만능 DB가 된 것 같음
게다가 무료임
이제 굳이 다른 SQL DB를 쓸 이유가 있을까 궁금함
Postgres는 훌륭하지만, MySQL은 마스터-마스터 복제가 더 쉽고, MongoDB는 지리적 분산과 샤딩이 간단함 Clickhouse는 분석용으로 훨씬 빠르고, Cassandra 같은 DB는 쓰기 중심 워크로드에 유리함
즉, 각 DB마다 여전히 강점이 있음
“모든 걸 잘한다”는 표현은 과장임
데이터가 많아지면 성능 저하나 마이그레이션 문제가 생김
내 경우, 기본 파티셔닝 성능이 떨어져서 직접 커스텀 파티션을 구현해야 했음
Postgres는 여전히 MVCC 구현 방식(copy-on-write)이 비효율적임
이 선택이 부하가 커질 때 여러 부정적 영향을 줌
예전에는 MySQL/InnoDB가 업데이트 중심 워크로드에서 더 나았음 Uber의 블로그 글에서도 다뤘던 주제임
그래도 클라우드 환경에서는 Postgres를 가장 신뢰함
Postgres에는 아직 Vitess 수준의 성숙한 대체재가 없음
그래서 대규모 OLTP 배포에서는 여전히 MySQL이 주로 쓰임 (예: YouTube, Uber)
불변 데이터 구조(HAMT) 를 이용하면 파일시스템 종류와 상관없이 즉시 클론이 가능한 DB를 만들 수 있음
이론이라고 말했지만 실제로 구현해봤음
왜 이런 HAMT 기반 DB가 더 많지 않은지 이해가 안 됨
나는 ClickHouse의 작성자인데, ClickHouse도 불변 데이터 파트를 사용해 테이블 복제를 지원함 관련 문서 링크
Datomic에도 이런 클로닝 기능이 내장되어 있는지 궁금함. 예전부터 써보고 싶었지만 실제 앱을 만들기엔 아직 마음의 준비가 안 됨
Postgres v15에서 WAL_LOG가 기본으로 바뀐 걸 몰랐음
병렬 CI 테스트 환경에서는 FILE_COPY 전략으로 되돌리는 게 더 합리적임
예전 프로젝트 integresql에 관련 이슈를 올렸음
로컬에서 Postgres 기반 앱을 테스트하기 위한 간단한 GUI 도구 pgtt 를 만든 적 있음
개발 환경 설정을 훨씬 단순화해줌
README만 봐서는 잘 모르겠는데, 템플릿을 스냅샷처럼 다루는 구조인지 궁금함
SQL 마이그레이션 반복 작업에 도움이 될 것 같음
README에 GUI 스크린샷이 있으면 좋겠고, Docker 링크가 깨져 있음
블로그의 다른 글들도 읽어봤는데 전반적으로 훌륭함
특히 Postgres의 range 타입을 처음 알게 되었음
range 타입은 시간/날짜 구간 겹침 계산 같은 데서 정말 유용함
MariaDB에서도 이런 기능이 있는지 궁금함
테스트마다 DB를 초기 상태로 되돌리는 게 느려서 고민 중임
프로덕션에서 MariaDB를 쓰기 때문에 DB를 바꾸긴 어려움
Postgres 쪽이 더 좋아 보이긴 함
각 테스트를 트랜잭션 세션 안에서 실행하고, 끝날 때 롤백하면 빠르게 초기 상태로 복원 가능함
이 방식이 꽤 효율적임
DB를 재시작해도 괜찮다면 LVM이나 btrfs 스냅샷을 파일시스템 레벨에서 사용하는 것도 방법임
Hacker News 의견들
기다릴 수 없거나 PG18의 완전한 인스턴스 격리가 필요한 사람들을 위해, 나는 ZFS 스냅샷을 이용해 즉시 브랜칭하는 도구 Velo를 만들었음
어떤 PostgreSQL 버전에서도 작동하며, 각 브랜치는 독립된 컨테이너와 포트를 가짐
100GB DB 기준 약 2~5초면 생성 가능함
PG18 방식과의 차이는, 단일 인스턴스를 공유하지 않고 완전한 서버 격리를 제공한다는 점임
GitHub 링크
예전에 회사가 RDS로 마이그레이션할 때 비슷한 시스템을 직접 구축했음
프로덕션 마이그레이션 중 자주 문제가 생겨서, 이를 방지하기 위해 다음 단계를 자동화했음
이 과정 덕분에 로컬이나 CI에서는 잡히지 않던 프로덕션 특유의 버그를 많이 잡을 수 있었음
이후 간단한 Ruby 스크립트로 자동화했고, 아직도 그 스크립트를 사용 중이라고 들었음
템플릿 클로닝 전략이 설정 가능하다는 걸 이번에 처음 알았음
나는 Neon을 이용해 실시간 통합 환경을 만들었고, 내 Golang 프로젝트 pgtestdb 에서는 각 테스트마다 완전한 스키마 마이그레이션이 적용된 Postgres DB를 생성함
예전에 스타트업에서 btrfs로 즉시 스테이징 DB를 만드는 걸 본 적 있는데, 비슷한 아이디어가 반복 등장하는 게 흥미로움
이런 빠른 복제와 테스트는 Postgres와 Sqlite의 큰 장점이며, Clickhouse나 MySQL에서도 가능했으면 좋겠음
요즘 PostgreSQL이 거의 모든 SQL 용도를 커버하는 만능 DB가 된 것 같음
게다가 무료임
이제 굳이 다른 SQL DB를 쓸 이유가 있을까 궁금함
Clickhouse는 분석용으로 훨씬 빠르고, Cassandra 같은 DB는 쓰기 중심 워크로드에 유리함
즉, 각 DB마다 여전히 강점이 있음
데이터가 많아지면 성능 저하나 마이그레이션 문제가 생김
내 경우, 기본 파티셔닝 성능이 떨어져서 직접 커스텀 파티션을 구현해야 했음
이 선택이 부하가 커질 때 여러 부정적 영향을 줌
Uber의 블로그 글에서도 다뤘던 주제임
그래도 클라우드 환경에서는 Postgres를 가장 신뢰함
그래서 대규모 OLTP 배포에서는 여전히 MySQL이 주로 쓰임 (예: YouTube, Uber)
불변 데이터 구조(HAMT) 를 이용하면 파일시스템 종류와 상관없이 즉시 클론이 가능한 DB를 만들 수 있음
이론이라고 말했지만 실제로 구현해봤음
왜 이런 HAMT 기반 DB가 더 많지 않은지 이해가 안 됨
관련 문서 링크
Postgres v15에서 WAL_LOG가 기본으로 바뀐 걸 몰랐음
병렬 CI 테스트 환경에서는 FILE_COPY 전략으로 되돌리는 게 더 합리적임
예전 프로젝트 integresql에 관련 이슈를 올렸음
로컬에서 Postgres 기반 앱을 테스트하기 위한 간단한 GUI 도구 pgtt 를 만든 적 있음
개발 환경 설정을 훨씬 단순화해줌
SQL 마이그레이션 반복 작업에 도움이 될 것 같음
블로그의 다른 글들도 읽어봤는데 전반적으로 훌륭함
특히 Postgres의 range 타입을 처음 알게 되었음
MariaDB에서도 이런 기능이 있는지 궁금함
테스트마다 DB를 초기 상태로 되돌리는 게 느려서 고민 중임
프로덕션에서 MariaDB를 쓰기 때문에 DB를 바꾸긴 어려움
Postgres 쪽이 더 좋아 보이긴 함
이 방식이 꽤 효율적임
AWS에서도 유사한 기능을 지원함
Aurora 클론 문서
통합 테스트용으로는 비현실적임