Supabase public 스키마 복원 리허설하기

정의

Supabase의 public 스키마에 있는 애플리케이션 데이터를 대상으로 범위를 한정한 내보내기·복원 리허설이다. 함께 제공되는 백엔드 서비스까지 복제하는 작업은 아니다.

관점

bear_dba (@bear_dba) (2026-11-04, Threads)

Supabase 데이터베이스 전체를 일반 PostgreSQL 대상으로 복원하는 대신 애플리케이션 소유의 public 스키마를 내보내라. 전체 덤프에서는 supabase_admin, authenticator 같은 Supabase 전용 역할 때문에 문제가 생길 수 있다. --no-owner와 --no-privileges로 소유권·권한 메타데이터를 제외하라. 출처의 덤프는 --schema=public, --clean, --if-exists도 사용하며 일반 SQL을 supabase_public.sql에 기록한다.

SQL을 불러오기 전에 대상에 필요한 확장을 준비하라. 예제는 uuid-ossp와 pgcrypto를 활성화하고 uuid_generate_v4()를 언급한다. psql -h localhost -p 5432 -U postgres -d my_target_db -f supabase_public.sql로 파일을 불러와라. 이를 완전한 서비스 복제가 아니라 공급업체 의존도를 줄이기 위한 이식성 리허설로 다뤄라.

auth.users는 public 밖에 있으므로 따로 고려하라. 별도의 Auth 내보내기와 애플리케이션 인증 변경이 필요할 수 있다. 비밀번호 해시 호환성은 출처에서 제기한 우려이며, 여기서 입증된 것은 아니다.

적용

• 테스트할 애플리케이션 데이터가 public에 있을 때 폐기 가능한 리허설 대상에 적합하다. 모든 스키마나 부가 서비스를 망라한 목록은 아니다.
• 이처럼 범위가 좁은 데이터베이스 실습을 둘러싼 API 경계, 서비스 교체, 전환 계획은 Supabase 데이터베이스 이전을 단계적으로 진행하기를 참고한다.
• 리허설은 Supabase를 떠날 시점 판단하기의 프로덕션 이탈 결정과 분리한다. 이식성을 테스트하는 것만으로 이전이 정당화되지는 않는다.
• SQL 이식성을 서비스 동등성과 동일시하지 말고 Supabase에서 함께 제공되는 백엔드의 맥락을 살펴본다.

한계

• 이번 위키 ingest에서는 덤프, 확장 생성, 복원을 실행하지 않았다. 행 정합성 확인, 제약조건·정책 검증, 롤백, 애플리케이션 수준 인수 테스트가 입증되지 않았다.
• 원본 명령어에는 형식이 잘못된 호스트 db.xxxx.supabase.,com이 들어 있다. 실행 가능한 연결 문자열로 고치지 않고 쓰인 그대로 보존했다. 여기에 나온 덤프 명령어는 테스트된 실행 절차가 아니다.
• 출처에는 --clean --if-exists가 있지만 파괴적 작업 검토나 안전한 대상인지 확인하는 절차는 없다. 프로덕션 적합성은 검증되지 않았다.
• 이 플래그로 어떤 일반 데이터베이스에든 오류 없이 가져올 수 있다는 주장, 눈에 보이는 오류가 없으면 성공이라는 주장, Auth가 유일한 약점이라는 주장은 입증되지 않았다. 스키마 간 의존성, 정책이 참조하는 역할, 확장 위치, 대상·버전 호환성은 평가하지 않았다.
• 비밀번호 해시 비호환성과 결국 이전이 필요하다는 말은 독립적으로 검증된 사실이 아니라 한 실무자의 주장이다. 설명된 public 전용 내보내기에는 Storage, Realtime, 전체 인증 서비스가 포함되지 않는다.

Original link