본문 바로가기
데이터베이스2026년 9월 19일8분 읽기

포스트그레SQL 19, 일정 밀렸다 — 베타 사이클에서 53개 기능 되돌림

YS
김영삼
조회 182
포스트그레SQL 19, 일정 밀렸다 — 베타 사이클에서 53개 기능 되돌림

포스트그레SQL 19의 정식 출시가 예정보다 늦어진다. 9월 출시를 기대했던 관례와 달리 현재 GA 일정이 확정되지 않았고, 베타 4가 2026년 9월 24일로 예정돼 있다. 릴리스 관리팀은 10월 말을 목표로 조정 중인 것으로 알려졌다.

지연보다 주목할 것은 범위 축소다. 베타 사이클 동안 53개 기능이 되돌려졌다. 18 사이클의 약 44개보다 많은 수치이며, SQL 속성 그래프 질의(SQL Property Graph Queries), ALTER TABLE MERGE/SPLIT PARTITION, GROUP BY ALL, TOAST lz4 압축 같은 간판급 항목이 포함됐다.

이런 뉴스를 보면 두 가지 반응이 갈린다. "역시 오픈소스는 일정이 안 지켜진다"는 쪽과 "제때 내놓는 것보다 잘못된 설계를 안 내놓는 게 낫다"는 쪽. 나는 후자에 가깝다. 데이터베이스는 한번 나간 기능의 문법과 동작이 수십 년 유지된다. 설계가 어긋난 채 나가면 그걸 되돌리는 비용이 훨씬 크다.

무엇이 빠졌나

되돌려진 주요 기능성격대기 중이던 활용
SQL Property Graph Queries표준 SQL 기반 그래프 질의관계형 안에서 그래프 탐색
ALTER TABLE MERGE/SPLIT PARTITION(S)파티션 병합·분할 DDL시계열 파티션 재구성 자동화
GROUP BY ALL질의 편의 문법분석 질의 작성 단순화
TOAST lz4 압축대용량 값 저장 압축 옵션대형 텍스트·JSONB 저장 효율

반대로 현재까지 남아 있는 것으로 언급되는 항목도 있다. 질의 힌트 성격의 pg_plan_advice, 병렬 오토배큠, ON CONFLICT DO SELECT, 윈도우 함수의 IGNORE NULLS 등이다. 다만 베타가 끝나기 전까지는 어느 것도 확정이 아니다. 이번 사이클이 보여 준 게 정확히 그 점이다.

왜 이렇게 많이 되돌려졌나

원인 분석으로 반복 지목되는 건 피처 프리즈 직전 커밋 집중이다. 4월 동결 직전에 들어온 패치들은 리뷰를 가장 적게 받은 상태로 들어온다. 그리고 여름 내내 진행된 커밋 후 리뷰에서 단순 버그가 아니라 설계 수준의 문제가 드러났다. 19의 간판 기능 여럿이 그 경로로 들어왔다.

소프트웨어 조직이라면 남 일이 아니다 마감 직전에 몰아 넣은 변경이 가장 위험하다는 건 모든 팀이 아는 사실이다. 그런데도 반복되는 이유는, 마감이 "넣을지 말지"가 아니라 "넣을 수 있는 마지막 순간"으로 작동하기 때문이다. 동결 시점을 앞당기는 것보다, 동결 직전 N일 동안은 리뷰 기간이 확보된 패치만 받는 규칙이 더 효과적이다.

업그레이드 계획에 미치는 영향

1
일정 재조정
19 GA를 전제로 한 마이그레이션 계획은 시점을 뒤로 미뤄야 한다. 10월 말 목표는 목표일 뿐 확정이 아니다.
2
기능 전제 재확인
되돌려진 기능을 전제로 설계한 부분이 있는지 점검한다. 특히 파티션 병합·분할을 자동화하려던 계획은 대안이 필요하다.
3
EOL 일정과의 간격 확인
구버전 지원 종료 일정을 함께 놓고 업그레이드 창을 다시 계산한다. 지연이 길어지면 창이 좁아진다.
4
베타 테스트 참여
업그레이드가 예정돼 있다면 베타 4로 실제 워크로드를 돌려 보고 문제를 보고하는 것이 가장 빠른 대비다.

파티션 병합·분할이 빠진 게 실무적으로 가장 아프다. 시계열 데이터에서 월 단위 파티션을 분기 단위로 합치거나 반대로 쪼개는 작업은 지금도 수작업 스크립트로 한다. 자동화 DDL을 기다리던 팀은 한 사이클 더 기다려야 한다.

-- 지금도 쓰는 우회 방법 (병합의 경우 대략적인 형태)
BEGIN;
-- 1) 대상 범위를 포괄하는 새 파티션 생성
CREATE TABLE events_2026q1 (LIKE events INCLUDING ALL);

-- 2) 기존 월 파티션에서 데이터 이동
INSERT INTO events_2026q1 SELECT * FROM events_202601;
INSERT INTO events_2026q1 SELECT * FROM events_202602;
INSERT INTO events_2026q1 SELECT * FROM events_202603;

-- 3) 분리 후 붙이기
ALTER TABLE events DETACH PARTITION events_202601;
ALTER TABLE events DETACH PARTITION events_202602;
ALTER TABLE events DETACH PARTITION events_202603;
ALTER TABLE events ATTACH PARTITION events_2026q1
  FOR VALUES FROM ('2026-01-01') TO ('2026-04-01');
COMMIT;
-- 주의: 대용량에서는 잠금 시간이 길다. 유지보수 창에서, 배치로 나눠 수행할 것.

평가 — 나쁜 소식인가

긍정적으로 볼 근거
  • 설계 결함이 GA 전에 발견됐다
  • 품질을 위해 범위를 줄이는 결정을 공개적으로 내렸다
  • 커밋 후 리뷰 문화가 실제로 작동한다는 증거
우려되는 지점
  • 되돌림 규모가 직전 사이클보다 크다
  • 동결 직전 커밋 집중이라는 구조적 문제는 그대로
  • 간판 기능 부재로 업그레이드 동기가 약해진다

사용자 입장에서 실질적 결론은 하나다. 19를 전제로 한 계획은 잠시 보류하고, 현재 버전의 EOL 일정을 기준으로 업그레이드 창을 다시 잡아라. 그리고 여유가 있다면 베타로 실제 워크로드를 돌려 보라. 지금 발견되는 문제는 GA 전에 고쳐질 수 있는 문제다.

출처

자주 묻는 질문

포스트그레SQL 19는 언제 나오나요?

현재 GA 일정이 확정되지 않았습니다. 베타 4가 2026년 9월 24일로 예정돼 있고, 릴리스 관리팀은 10월 말을 목표로 조정 중인 것으로 알려졌습니다. 통상적인 가을 출시 일정보다 수 주에서 수 개월 늦어질 수 있습니다.

어떤 기능이 빠졌나요?

베타 사이클 동안 53개 기능이 되돌려졌습니다. SQL 속성 그래프 질의, ALTER TABLE MERGE/SPLIT PARTITION, GROUP BY ALL, TOAST lz4 압축 등 간판급 항목이 포함됩니다. 대부분 커밋 후 리뷰에서 설계 결함이나 버그가 발견된 것이 이유입니다.

왜 이렇게 많이 되돌려졌나요?

4월 피처 프리즈 직전에 몰려 들어온 패치들이 충분한 리뷰를 받지 못한 상태였고, 여름 동안의 커밋 후 리뷰에서 단순 버그가 아닌 설계 수준의 문제가 드러났기 때문입니다. 릴리스팀은 일정보다 품질을 우선해 범위를 줄이는 선택을 했습니다.

지금 18에서 19로 업그레이드를 준비해도 되나요?

계획 자체는 유지하되 시점을 뒤로 미루는 것이 안전합니다. 되돌려진 기능을 전제로 설계한 부분이 있다면 대안을 마련해야 합니다. 업그레이드가 확정된 팀이라면 베타 4로 실제 워크로드를 검증해 문제를 미리 보고하는 것이 가장 효과적입니다.

파티션 병합·분할은 어떻게 대체하나요?

현재는 새 파티션을 만들고 데이터를 이동한 뒤 DETACH/ATTACH로 교체하는 수작업 방식이 일반적입니다. 대용량에서는 잠금 시간이 길어지므로 유지보수 창에서 배치로 나눠 수행하고, 작업 전 반드시 백업과 실행계획 확인을 거치세요.

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록