2026 PostgreSQL 14 업그레이드, pg_upgrade에 디스크 공간을 얼마나 남겨야 할까?

PostgreSQL 공식 버전 지원 정책에 따르면 PostgreSQL 14의 지원 종료일은 2026년 11월 12일입니다. 공식 지원 일정을 기준으로 업그레이드를 준비하되, PostgreSQL 14 pg_upgrade 디스크 공간에는 모든 인스턴스에 적용되는 고정 배수가 없습니다. 먼저 데이터 디렉터리, 표 공간, WAL 위치를 확인하고 copy, link 또는 지원되는 clone 방식에 따라 필요한 공간과 되돌리기 위험을 계산해야 합니다.

판정 — 적합: 지원 종료 전에 운영 데이터베이스의 업그레이드 공간과 방식을 결정해야 하는 팀에 적합합니다.
PostgreSQL 14 운영을 맡은 DBA라면 기존 파일 배치와 복구 조건을 확인할 수 있습니다.
데이터베이스 서버 용량을 검토하는 SaaS 기술 책임자와 마이그레이션을 실행하는 엔지니어도 대상입니다.

마지막 업데이트: 2026년 11월 13일. PostgreSQL 공식 지원 정책과 대상 버전의 pg_upgrade 문서를 기준으로 확인했습니다.

먼저 파일시스템 사용량과 실제 경로를 확인합니다

데이터베이스의 논리 크기만으로 필요한 디스크를 산정하면 안 됩니다. 실제 파일은 데이터 디렉터리뿐 아니라 별도로 지정한 표 공간에도 있을 수 있고, WAL 디렉터리 위치도 데이터와 다를 수 있습니다. PostgreSQL 파일 배치 문서는 이런 디렉터리 구조를 설명하며, 표 공간은 별도 위치에 둘 수 있습니다. 표 공간 문서도 함께 확인합니다.

마이그레이션 전에 운영체제 도구로 각 경로의 사용량과 여유 공간을 기록합니다. df로 파일시스템별 여유 공간을 확인하고, du로 데이터 디렉터리와 각 표 공간의 실제 사용량을 조사합니다. WAL 경로가 분리되어 있다면 그 파일시스템도 따로 점검합니다. 대상 클러스터를 새로 만들 위치와 업그레이드 중 생성될 임시 파일의 위치도 목록에 넣습니다.

pg_upgrade --check가 빈 공간까지 보장하나요? 아닙니다. 이 옵션은 업그레이드 전에 호환성 등 조건을 점검하는 용도이지, 실제 실행 시점의 여유 공간이나 모든 파일시스템 상황을 보증하는 디스크 용량 확인서가 아닙니다. PostgreSQL 18 pg_upgrade 문서와 PostgreSQL 17 pg_upgrade 문서의 선택 항목과 제한을 확인하고, 실제 파일 배치에 따른 용량은 별도로 계산해야 합니다.

공간이 빠듯하다면 link의 복구 조건부터 따집니다

--link는 기존 데이터 파일을 복사하는 대신 새 클러스터에서 연결해 사용하므로 복사 방식보다 추가 데이터 사본이 차지하는 공간을 줄일 수 있습니다. 하지만 이 방식은 새 클러스터와 기존 클러스터의 파일시스템 조건을 충족해야 합니다. 실제 디렉터리 배치와 대상 버전 문서에서 허용되는 조건을 확인한 뒤에만 후보로 삼습니다.

특히 link는 공간 절약을 위한 무상 회귀 수단이 아닙니다. 새 클러스터를 시작한 뒤에는 기존 클러스터를 이전 상태 그대로 다시 사용하는 방식으로 되돌릴 수 없습니다. 따라서 문제가 생겼을 때의 복구는 정상 동작하던 백업과 검증된 복원 절차에 의존합니다.

link 방식으로 공간을 아끼고 실패하면 되돌릴 수 있나요? 공간 부담은 낮출 수 있지만, 새 클러스터를 시작한 뒤 기존 클러스터를 그대로 되살리는 회귀 경로로 간주해서는 안 됩니다. 먼저 기기 밖에 보관한 백업을 실제로 복원해 보고, 애플리케이션 전환과 복구 순서를 문서화해야 합니다. 백업과 복구 문서를 참고해 백업 방식과 복구 절차를 함께 검토합니다.

여유 공간이 있으면 copy와 clone을 비교합니다

copy는 기존 파일을 보존하면서 새 클러스터용 파일을 복사합니다. 그러므로 기존 클러스터와 새 클러스터가 동시에 존재할 기간의 공간을 모두 계산해야 합니다. 마이그레이션 중에 데이터가 더 늘거나 WAL이 쌓이는 운영 환경이라면, 현재 사용량만 딱 맞춰 잡는 방식은 위험합니다.

clone은 지원되는 운영체제와 파일시스템의 복제 기능을 활용해 공간 사용과 기존 클러스터 보존 측면에서 이점이 있을 수 있습니다. 다만 어느 환경에서나 쓸 수 있는 빠른 복사 방식은 아닙니다. 문서에 명시된 지원 조건을 충족하지 못하면 선택할 수 없습니다. 아래 비교는 용량을 확정하는 표가 아니라, 실제 환경에서 확인할 항목을 정리한 것입니다.

마이그레이션 경로가 달라지면 계산 항목도 달라집니다. 독립된 대상 환경으로 옮긴다면 원본 쪽 보존 공간과 대상 쪽 새 클러스터 공간을 따로 적습니다. 그 밖에 임시 사본과 전환 중 WAL이 어디에 생기는지도 확인합니다. 원본의 여유 공간을 대상 환경의 용량처럼 계산하지 마세요.

백업과 되돌리기를 업그레이드 계획에 포함합니다

업그레이드 전 백업, 기존 클러스터 보존, 새 클러스터 공간은 서로 다른 보호 조건입니다. 어느 하나를 확보했다고 나머지까지 충족되는 것은 아닙니다. 파일시스템 수준 백업을 사용할 때는 PostgreSQL의 파일시스템 백업 안내에서 일관성 조건을 확인하고, 데이터 디렉터리와 표 공간 등 필요한 파일이 빠지지 않는지 점검합니다.

PostgreSQL 대규모 버전 업그레이드에서는 copy와 link 중 무엇이 더 안전한가요? 기존 클러스터를 유지할 여유 공간과 검증된 복구 수단이 있다면 copy가 회귀 계획을 세우기 쉬울 수 있습니다. 공간이 빠듯해 link를 검토하더라도, 백업 복원이 확인되지 않았다면 운영 전환을 진행하지 않는 편이 안전합니다. 선택은 공간만이 아니라 복구 조건과 실제 파일 배치로 결정합니다.

운영 전에 다음 항목을 하나씩 확인합니다.

• [ ] 데이터 디렉터리, 모든 표 공간, WAL 위치를 찾아 파일시스템별 사용량과 여유 공간을 기록합니다.
• [ ] 대상 클러스터 경로와 임시 파일이 만들어질 경로를 확정하고 각각의 여유 공간을 확인합니다.
• [ ] 대상 버전의 pg_upgrade 문서에서 copy, link, clone의 제한과 파일시스템 조건을 대조합니다.
• [ ] 격리된 환경에서 팀의 데이터와 실제 절차로 실행해 공간 사용 내역을 기록합니다.
• [ ] 기기 밖에 둔 백업을 복원하고, 애플리케이션 전환과 되돌리기 절차를 검증합니다.
• [ ] --check 결과를 용량 보증으로 취급하지 않고, 운영체제의 파일시스템 여유 공간을 별도로 다시 확인합니다.

복제나 소프트웨어 RAID는 디스크 고장에 대비하는 구성일 수 있지만, 기기 밖 백업을 대신하지 않습니다. 독립 서버를 사용하더라도 데이터 손실을 막으려면 백업 복원을 직접 시험해야 합니다.

점검 결과를 방식과 저장 공간 계획으로 옮깁니다

아래 표에 측정값을 직접 채운 뒤 마이그레이션 경로와 함께 검토합니다. 특정 데이터 크기에 일정한 여유 배수를 곱해 결론 내리기보다, 각 경로가 실제로 사용하는 파일시스템을 기준으로 계획해야 합니다.

용량이 모자라면 서버부터 바꿔야 하나요? 먼저 파일 배치, 마이그레이션 방식, 원본 보존 기간을 다시 검토합니다. 그 뒤에도 필요한 공간이나 복구 조건을 충족할 수 없다면 별도 대상 환경을 마련하는 방안을 비교합니다. 서버를 바꾸는 것만으로 업그레이드 시간이 단축되거나 데이터 보호가 보장되는 것은 아닙니다.

관리형 데이터베이스는 운영 부담을 줄여줄 수 있지만, 서비스에 따라 저장공간이나 성능 등급의 선택 폭과 비용 구조가 다를 수 있습니다. 공유형 클라우드 인스턴스는 물리 자원을 독점하지 않으며, 파일시스템과 디스크 배치를 직접 제어하는 데 제약이 있을 수 있습니다. 반대로 운영 인력을 줄이는 일이 가장 중요하거나 짧은 기간만 쓰는 환경이라면 관리형 서비스나 공유형 인스턴스가 더 알맞을 수 있습니다.

지속적으로 운영하는 데이터베이스에서 자원 독점과 저장장치 배치 제어가 중요하다면, 독립 AMD 물리 서버도 검토 대상입니다. 다만 필요한 용량과 백업 구조를 먼저 정한 뒤 XFP Cloud 서버 구성 안내와 결제 주기 및 청구 안내를 대조해야 합니다. 가격과 실제 제공 구성을 확인하기 전에는 가용 용량을 가정하지 마세요. 데이터 디렉터리, 표 공간, WAL 위치, 선택한 이전 방식이 정리되지 않았거나 백업 복원이 검증되지 않았다면 생산 환경 전환부터 예약하지 않는 것이 좋습니다.