11월 12일 종료되는 것은 무엇인가
PostgreSQL 프로젝트의 공식 버전 정책에 따르면 14 계열은 2026년 11월 12일을 마지막 지원일로 한다. 10월 31일 기준 최신 14 마이너 릴리스는 14.24다. 지원 종료 후 데이터베이스가 즉시 정지하거나 접속이 차단되는 것은 아니지만, 커뮤니티의 후속 버그·보안 수정 릴리스를 더 이상 기대할 수 없다. [S01][S04]
따라서 서비스를 바로 중지할 필요가 있다는 뜻은 아니다. 그러나 규제·보안 감사와 취약점 대응 측면에서는 미지원 상태로 방치할 이유가 줄어든다. 운영팀은 사용 중인 DB 엔진, 관리형 서비스의 자체 지원 정책, 연동 드라이버와 확장 기능부터 식별해야 한다.
19 정식 출시를 기다릴까, 18로 옮길까
PostgreSQL 19는 10월 15일 첫 릴리스 후보(RC1)가 공개됐지만, 10월 31일 기준 일반 사용을 위한 정식 출시(GA)가 아니다. 프로젝트는 11월 12일 RC2, 11월 19일 GA를 계획하고 있으며 일정은 변경될 수 있다. RC 버전은 테스트용으로 취급해야 한다. [S02]
14를 운영 중이고 지원 종료 전에 이관해야 한다면 정식 지원 중인 15·16·17·18 계열 가운데 애플리케이션과 드라이버가 검증된 목표 버전을 먼저 검토하는 편이 현실적이다. 지원 정책상 15는 2027년 11월, 16은 2028년 11월, 17은 2029년 11월, 18은 2030년 11월에 지원이 끝날 예정이다. 숫자가 큰 버전을 무조건 선택하기보다 확장 기능 호환성과 서비스 변경 허용 시간을 함께 평가해야 한다. [S01]
특히 19의 정식 출시 예정일은 14의 지원 종료일보다 7일 뒤다. 14 운영 시스템의 보안 대응 일정을 미확정 19 GA에만 의존해 잡는 것은 피해야 한다.
업그레이드 전에 확인할 항목
첫째, 현재 서버의 전체 버전과 확장 모듈을 조사한다. SELECT version(); 와 SELECT extname, extversion FROM pg_extension; 결과를 저장하고, pg_stat_activity 및 애플리케이션 커넥션 풀의 접속 패턴도 확인한다.
둘째, 데이터 용량·테이블스페이스·복제 구성·백업 크기·RPO/RTO를 정리한다. pg_dump/pg_restore 방식은 재구성 시간이 길 수 있고, pg_upgrade는 일반적으로 더 빠른 메이저 이관 경로지만 사전 조건 및 확장 호환성을 확인해야 한다. 논리 복제 기반 이관도 가능하나 시퀀스·DDL·쓰기 전환 등을 따로 설계해야 한다. [S03]
셋째, SQL·ORM·JDBC/드라이버·인덱스·실행 계획·배치 쿼리·권한·확장 모듈을 새 버전에서 리허설한다. 메이저 버전 변경에는 사용자에게 보이는 동작 차이가 존재할 수 있으므로 버전별 릴리스 노트의 Migration 항목을 확인한다. [S03]
실무 전환 순서와 롤백 설계
권장 순서는 ① 복구 가능한 백업과 복구 테스트 ② 스테이징 복원 ③ 쿼리·확장·복제 호환 검증 ④ 실제 규모 기반 소요 시간 측정 ⑤ 쓰기 중단 및 컷오버 계획 ⑥ 무결성·성능 관찰 순서다. 복구 테스트가 없는 백업은 실제 대응 능력을 입증하지 못한다.
pg_upgrade 또는 dump/restore를 사용해 메이저 버전을 올린 뒤 새 데이터 디렉터리를 단순히 옛 실행 파일로 열어 다운그레이드할 수 있다고 가정하면 안 된다. 롤백은 기존 서버·스냅샷·백업을 별도로 유지하고, 컷오버 이후 발생한 데이터 쓰기를 어떻게 처리할지 정의해야 한다. [S03]
클라우드 관리형 PostgreSQL이라면 서비스 제공사의 지원 종료·업그레이드 가능 버전·정지 시간·자동 스냅샷·읽기 복제본 정책이 커뮤니티와 다를 수 있다. 제품별 안내를 별도 확인한 뒤 변경 창을 확정한다.
운영 전환 전 추가 검증: 실패 시 복구 가능한가
업그레이드를 실행하기 전에는 대상 버전의 바이너리·확장 모듈을 준비하고 pg_upgrade --check로 사전 호환성 검사를 실시한다. 이 검사가 성공해도 실제 전환 성공이나 애플리케이션 정상 동작을 보장하지 않으므로, 운영 데이터의 복제본에서 전체 이관과 핵심 쿼리·배치를 리허설해야 한다. [S03]
복구 계획에는 복원 가능한 백업, 컷오버 전 구버전 서버 보존, 쓰기 중단 시점, DNS·연결 문자열 전환, 실패 판정 기준, 복귀 담당자를 명시한다. 특히 pg_upgrade --link 등 데이터 파일 공유 방식은 구버전 데이터 디렉터리를 독립된 롤백 수단으로 간주할 수 없으므로, 별도 복구 가능한 복제본을 확보한다. 새 버전에서 쓰기가 시작된 후 구버전으로 되돌리려면 해당 쓰기 데이터의 처리 전략을 별도로 마련해야 한다. [S03]
결론: 오늘 해야 할 결정
PostgreSQL 14 운영자는 지금 버전 현황과 업그레이드 목표를 확정하고, 백업 복원 실험 및 핵심 애플리케이션 회귀 테스트를 시작해야 한다. PostgreSQL 19는 주목할 차기 릴리스지만 현재는 RC 단계이므로 ‘출시 예정’과 ‘지금 운영 적용 가능’을 구분해야 한다. [S01][S02]
지원 종료를 앞둔 버전 관리의 핵심은 새 기능 확보보다 데이터 복원 가능성, 애플리케이션 호환성, 그리고 실제 장애 시 되돌릴 수 있는 전환 절차를 확보하는 데 있다.
