같은 PostgreSQL, 다른 운영 환경

내용 검토: 2026. 09. 28.

결론부터

SQL과 데이터 원리는 재사용하되 관리자 권한·복제 구조·연결·복구 기능은 환경마다 확인한다.

새 환경으로 옮길 때 SQL을 처음부터 다시 배울 필요는 없다. 하지만 서비스가 제공하는 권한과 백업·고가용성 방식을 직접 운영하던 PostgreSQL과 같다고 가정해서도 안 된다.

이 장에서 처음 나오는 말3개

관리형 DBManaged database: 제공자가 일부 인프라·유지 관리 절차를 맡는 서비스. 앱 설계 책임까지 사라지지는 않는다.
RDS for PostgreSQL: AWS에서 PostgreSQL을 관리형 서비스로 제공하는 선택지.
Aurora PostgreSQL: Aurora의 저장·가용성 구조를 사용하는 PostgreSQL 호환 엔진.

어디서나 쓸 지식

테이블과 제약을 설계하고, JOIN 결과를 예측하고, 트랜잭션·잠금·실행 계획을 읽는 지식은 공통 기반이다. 권한을 앱의 실제 신원으로 검증하고 백업을 복원해 확인하는 원칙도 같다. 다만 지원 SQL·확장·기능의 세부 동작은 서버 버전과 제품 문서를 함께 확인한다.

달라지는 운영 책임

환경	맡길 수 있는 부분	직접 판단할 핵심
온프렘 CNPG	operator가 선언한 DB 운영 절차를 자동화	Kubernetes·스토리지·장애 영역·인증서·백업 저장소와 복원
Supabase	제공 환경에 따른 DB 운영과 Auth·API 등 통합	스키마·RLS·API 노출 범위·연결 방식·플랜별 복구 기능
RDS for PostgreSQL	AWS의 DB 인프라와 관리 기능	배치·접근·파라미터·권한·확장·HA/백업 옵션·앱 복구
Aurora PostgreSQL	Aurora의 저장 계층과 클러스터 운영 기능	writer/reader·endpoint·호환성·복제/복구의 서비스별 의미

Supabase 프로젝트의 DB는 실제 PostgreSQL이다. Auth·Storage·Realtime 같은 서비스가 그 위에 연결되므로 제품별 스키마와 역할을 이해해야 한다. (Supabase 데이터베이스)

RDS에서는 관리 계정도 일반 설치의 완전한 superuser와 같지 않다. 서버 파일 접근·확장 설치·설정 변경 권한은 서비스가 허용하는 범위에서 이뤄진다. (RDS PostgreSQL role)

Aurora는 PostgreSQL 호환 엔진이며 DB 인스턴스와 분산된 클러스터 저장 계층의 관계가 CNPG의 인스턴스별 PVC·물리 standby 구성과 다르다. CNPG의 복제 YAML과 장애 모델을 그대로 적용하지 않는다. (Aurora PostgreSQL, Aurora 저장 구조)

환경을 옮기기 전에 적을 것

확인 항목	구체적인 질문
버전·확장	원본과 대상의 major, collation, 확장 버전·지원 범위는?
객체·권한	소유자·role·RLS·함수·트리거가 같은 의미로 동작하는가?
연결	직접 연결·풀러·TLS·네트워크·쓰기 endpoint는 무엇인가?
데이터 이동	논리 dump·논리 복제 등 지원 경로와 쓰기 중단 시간은?
검증	행 수·업무 쿼리·권한·시퀀스·앱의 재시도 결과를 어떻게 확인하는가?
복구	원본으로 돌아갈 때 새 쓰기와 외부 파일은 어떻게 처리하는가?

Supabase의 auth.uid() 같은 함수와 서비스 관리 스키마는 앱의 의존성이다. PostgreSQL 백업을 다른 곳에 복원했다고 Supabase의 API·인증 서비스까지 함께 생기는 것은 아니다. 같은 이유로 DB 백업이 외부 오브젝트 파일까지 담는다고 가정하지 않는다.

기존 덱에서 이어 읽기

온프렘 CNPG: 사내 플랫폼에서 DB와 스토리지·S3·관측을 연결한다.
Supabase의 Postgres 최소 지식: Auth 사용자와 profiles 등 제품 적용으로 연결한다.
AWS의 컴퓨팅·데이터 서비스: RDS의 가용성 선택을 다른 AWS 구성과 함께 본다.

이해 확인: 세 환경에서 같은 SQL이 실행되면 장애 전환과 PITR 절차도 같을까? 아니다. SQL 호환성과 운영 제어면의 기능·책임은 별도로 확인한다.