Postgres 19의 새로운 점: 베타 릴리스 심층 분석

 (snowflake.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 대규모 프로덕션 데이터베이스를 위한 REPACK CONCURRENTLY 가 코어에 내장되고, SQL 속성 그래프 쿼리·논리적 복제·VACUUM·성능 등 전 영역에 걸친 폭넓은 개선이 담긴 베타 릴리스
  • 파티션 병합·분할 지원과 시퀀스 값 동기화로 운영 중 설계 변경과 데이터 이동이 한층 수월해짐
  • 오토배큠에 병렬 워커와 우선순위 점수 체계가 도입되어 유지보수 작업의 처리량과 가시성 향상
  • SQL/PGQ 도입으로 관계형 모델을 버리지 않고 기존 데이터를 그래프 형태로 조회 가능
  • 단일 헤드라인 기능이 아닌 폭넓음(breadth) 이 핵심으로, 애플리케이션·운영·성능·확장성 전반에서 동시에 발전

REPACK 기본 내장

  • 테이블 블로트 회수, 테이블 재작성, 데이터 재구성 시 VACUUM FULL이나 CLUSTER가 동반하는 락을 피하려는 상황이 오랜 운영 환경에서 반복적으로 발생
    • 이 문제를 해결하는 확장 생태계가 존재했고, 대표적으로 pg_repack 이 그 공백을 채워옴
  • Postgres 19는 REPACK 명령을 코어로 도입하며, REPACK CONCURRENTLY 지원 포함
    • 평균적인 릴리스 노트 독자가 예상하는 것보다 프로덕션 사용자가 더 주목할 기능으로 기대됨

파티셔닝의 실용성 강화

  • Postgres 19는 파티션 병합·분할 지원을 추가
  • 파티셔닝 전략은 불완전한 정보로 선택되며, 워크로드·보존 기간·데이터 증가 속도가 바뀌면 일부 파티션이 비대해지거나 지나치게 작아지는 문제 발생
  • 분할·병합 가능으로 처음부터 전부 재구성하지 않고 시간에 따라 설계를 진화시킬 여지 확보
    • Q1·Q2 파티션을 단일 파티션으로 병합: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Q3 파티션을 월 단위로 분할하는 SPLIT PARTITION 예시 제공

논리적 복제의 성숙

  • 논리적 복제는 마이그레이션, 업그레이드, 리포팅 시스템, 데이터 이동, 선택적 복제, 고가용성·운영 워크플로에 유용
  • 가장 큰 개선은 시퀀스 값 동기화로, 구독자가 발행자와 더 잘 일치
    • 시퀀스 상태 없이 복제 시 데이터는 이동하나 다음 생성 ID가 어긋나는 cutover 후 문제 발생
    • 발행에 ALL SEQUENCES 지원, 시퀀스 동기화 오류 보고, 시퀀스 관련 구독 갱신 동작 개선 추가
  • 발행 시 모든 테이블을 게시하면서 일부를 제외하는 EXCEPT 절 사용 가능
  • wal_level = replica 가 필요 시 논리적 복제를 자동 활성화, 실제 동작을 보고하는 새 effective_wal_level 추가로 설정 실수 감소와 가시성 향상

더 똑똑하고 잘 보이는 오토배큠

  • 오토배큠이 병렬 배큠 워커를 사용할 수 있으며, 전역 및 테이블 단위로 제어 가능
    • 전역 설정 예시: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • 테이블이 배큠되는 순서를 제어하는 새 점수 체계 도입으로 어떤 테이블이 가장 시급한지 우선순위 판단 개선
    • 테이블별 가중치 조정 예시: insert 기반 배큠 긴급도 3.0, 일반 update/delete 배큠 긴급도 0.5
  • 새 pg_stat_autovacuum_scores 뷰로 의사결정 과정 가시성 제공
    • 배큠·분석 진행 뷰의 상세 정보, VACUUM VERBOSE와 오토배큠 로그의 메모리 사용량·병렬성, 별도 log_autoanalyze_min_duration 추가로 유지보수 관찰성 강화

SQL 속성 그래프 쿼리 도입

  • SQL/PGQ(SQL property graph queries) 추가
    • 정점·간선 모델이 유용한 워크로드로 사기 탐지, 추천, 네트워크 분석, 권한 그래프, 공급망, 조직도 등 명시
    • 속성 그래프 정의 예시: CREATE PROPERTY GRAPH store_graph로 VERTEX TABLES와 EDGE TABLES 지정
  • 관계형 모델을 버리지 않고, 이미 보유한 데이터를 조회하는 또 다른 방법을 추가하는 방식
    • JSONB, 전문 검색, 확장이 기존 아키텍처 변경을 강요하지 않았던 것과 동일한 흐름
  • 개발자 관점에서 별도 데이터스토어, 동기화 경로, 운영 표면적, 새벽 2시 디버깅 대상을 늘리지 않고 그래프형 쿼리 사용 가능

더 유용해진 COPY

  • COPY FROM 이 여러 헤더 라인 건너뛰기 지원
    • 상단에 추가 메타데이터 라인이 붙은 벤더·내부 도구·export CSV 처리에 유용
  • COPY FROM 에 ON_ERROR SET_NULL 추가로 잘못된 입력값을 null로 설정, "전체 로드 실패"와 "사전 정제" 사이의 선택지 제공
    • price 컬럼에 'N/A'·'MISSING'이 섞인 파일 로드 예시 제공
  • COPY TO 가 단일 JSON 배열을 포함한 JSON 형식 출력 가능, 파티션 테이블도 직접 출력 가능(이전에는 COPY (SELECT ...) 필요)
    • 테이블을 유효한 JSON 배열로 내보내는 예시: WITH (FORMAT JSON, ARRAY true)

SQL 편의성 개선

  • GROUP BY ALL 로 비집계·비윈도우 대상 목록 표현식을 자동 그룹화, 탐색적 SQL·리포팅 쿼리를 더 깔끔하게 작성
  • 윈도우 함수에 IGNORE NULLS·RESPECT NULLS 지원이 lead, lag, first_value, last_value, nth_value에 추가
  • INSERT ... ON CONFLICT DO SELECT ... RETURNING 추가로 upsert에서 충돌 행을 더 직접 반환
  • UPDATE·DELETE FOR PORTION OF 추가로 시간(temporal) 관련 작업 지원 지속, 확장된 RANDOM() 시간 함수 포함

전반에 걸친 성능 개선

  • 플래너와 실행기에 anti-join, semi-join, constant folding, append 경로의 incremental sort, 조인 전 집계 처리, 조인 선택도 계산, 함수 통계 등 다수 개선
  • Postgres가 흔한 쿼리의 형태를 더 잘 인식하고 불필요한 작업을 줄이는 방향으로 발전
    • 일부 집계 처리가 조인 전에 수행되어 처리 행 수 감소
    • 더 많은 NOT IN·LEFT JOIN 사례가 효율적 anti-join으로 전환
    • Memoize의 EXPLAIN 가시성 향상, radix sort로 정렬 성능 개선, 외래 키 제약 검사 속도 향상, COPY FROM 텍스트·CSV 입력에 SIMD 명령 활용
  • 다수의 경우 애플리케이션 코드 변경 없이 업그레이드만으로 더 나은 동작 가능

Postgres 19가 중요한 이유

  • 단일 기능이 아닌 폭넓음(breadth) 이 두드러짐
    • 애플리케이션 개발자용: 그래프 쿼리, 향상된 SQL 구문, 윈도우 함수 개선, 더 나은 upsert 동작
    • 운영자용: REPACK CONCURRENTLY, 개선된 오토배큠, 향상된 모니터링, 온라인 체크섬 변경, 복제 가시성 확대
    • 성능 중시 사용자용: 플래너 개선, SIMD 개선, 비동기 I/O 가시성, 빠른 외래 키 검사, 개선된 정렬
    • Postgres 위에서 구축하는 사용자용: 새 훅, 플래너 어드바이스 모듈, 확장 개선, FDW 통계 검색, 확장 생태계 투자 지속
  • 단일 워크로드·페르소나가 아닌 애플리케이션·운영·분석·확장 데이터베이스이자 플랫폼으로서 동시에 발전
  • 아직 GA가 아니므로 지금이 테스트 시점 — 애플리케이션 실행, 마이그레이션 테스트, 확장 점검, 주요 쿼리 플랜 확인, 논리적 복제·유지보수 워크플로 점검 필요

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Postgres, Oracle, MS SQL Server, MySQL을 실전 프로젝트에서 써봤고 SQLite는 깊게 써보진 않았지만 훌륭한 선택지로 알고 있음
    요즘은 스스로를 위해 Oracle과 MySQL/MariaDB는 항상 피함
    Postgres는 훌륭하지만, 가벼운 연결과 동기 갱신되는 구체화 뷰가 있었으면 함. 연결 풀러가 상황을 개선해도 동시 연결당 메모리 사용량이 여전히 비정상적으로 크고, SQL Server의 인덱스 뷰 같은 기능은 복잡한 데이터 상황에서 우아하고 사소하며 항상 맞는 구현을 가능하게 해줌
    SQL Server는 비쌀 수 있지만 많은 경우 비용만큼의 가치가 있고, 데이터 저장소를 신중히 고르면 미래의 골칫거리를 많이 줄일 수 있음

    • 관계형 저장소 문제에는 SQLite와 MSSQL을 주로 씀
      무료 제공자를 쓸 거라면 SQLite를 이기기 어렵고, 현재 대부분의 사용 사례를 감당함. 다만 백업, 복제, 도구 면에서는 무너지기 시작함. 시스템 가용성과 재해 복구를 책임져야 한다면 돈을 써서 리스크를 줄이는 데 거리낌이 없음
      돈을 조금이라도 낼 거라면 끝까지 감. MSSQL 주변의 개발자 경험은 독보적이고, SSMS와 Visual Studio의 SQL 프로젝트는 요즘 Entity Framework류보다 훨씬 낫다고 봄. RedGate 같은 서드파티 도구까지 더하면 수백만 달러짜리 컨설팅 패키지를 대체할 수 있음
      새 Oracle이나 DB2 서버를 세우자고 하지는 않겠지만, 이미 있다면 없애려고 리팩터링하는 것에는 끝까지 반대할 듯함. 이런 데이터베이스에는 대개 방대한 괴담이 딸려 있고, 그 이상한 부작용들을 새 엔진에서 재현하려다 다른 선택지가 없으면 사업 자체가 망가질 수 있음
    • Oracle은 고통, 괴로움, 높은 비용, 소송, 인간적 비참함의 조합임. 비싼 소프트웨어를 사면 좋은 파티 같은 혜택을 받는 걸 좋아하는 비기술 중간관리자가 아니었다면 이미 망했을 것 같음
    • Microsoft조차 SQL Server를 사실상 포기하고 Azure의 여러 Postgres 제품 개선에 더 시간을 쓰는 것 같음. 2022년 이후 마지막 주요 버전은 AI 기능 몇 개를 더한 정도였음
      DBA로서 무거운 DBA 작업을 많이 해보면 Postgres는 SQL Server와 다른 급임. Postgres는 Linux 네이티브이고 오픈소스라서 유연성, 내부 관찰 가능성, 운영성이 SQL Server와 비교가 안 됨
      현재 기술 지형에서 SQL Server는 사실상 죽었다고 봄. 쓰는 회사는 레거시 Windows 중심 조직뿐이고, 그런 곳도 점점 줄어드는 중임
    • 동기 갱신 구체화 뷰가 정말 있으면 좋겠음. Oracle 용어로는 “commit 시 갱신” 같은 것을 말하는 듯함
      여기에 지연 갱신 옵션도 있으면 좋겠음. 마지막 새로고침 이후 바뀐 레코드만 고려해 여러 업데이트를 한 번에 처리하는 방식인데, Oracle이 기술적으로 어떻게 하는지는 잘 모르겠음. 이 기능은 거의 모든 오픈소스 OLTP 데이터베이스 대비 환상적인 추가 기능이 될 것 같음
      OrioleDB 프로젝트도 정말 궁금함: https://github.com/orioledb/orioledb/releases
      몇 년 전 임시 테이블 비슷한 곳에 지속적인 무작위 삽입·삭제가 많이 일어나서 vacuum 때문에 꽤 고생했음. RAM에 변경을 더 모았다가 테이블에 flush해서 페이지당 변경 행 수를 늘리는 방식으로 해결했지만, 좋은 균형을 찾느라 많이 애먹었음
    • PostgreSQL이 더 나은 제품이긴 하지만 MySQL/MariaDB의 수평 확장성은 없음. 그래서 설정 쉬운 클러스터가 필요하고 대용량 온라인 리테일 스토어 같은 경우라면 MySQL이 여전히 쓸모 있음

  • 과학 분야에서 Postgres를 15년 넘게 써온 입장에서, PostgreSQL에 컬럼 지향 저장소가 없는 점이 걱정되기 시작함
    데이터셋이 점점 커지면서 PG 저장소의 한계가 점점 더 크게 느껴짐. cetus 같은 여러 확장이 기능을 제공할 수는 있지만, 그러면 그 확장이 앞으로도 지원될지에 의존해야 하고 복잡성도 늘어남

    • 약간 뻔뻔한 홍보지만, 몇 달 동안 이 문제를 확장 형태로 작업해왔음: https://github.com/xataio/deltax
      처음에는 Postgres 테이블을 저장소로 쓰고 Postgres 실행기를 쓰면 본질적인 오버헤드가 너무 클 것 같아서, Timescale 성능에 맞추면 꽤 멋지겠다고 생각했음. 전용 분석 데이터베이스에 가까워질 수 있다고는 생각하지 않았음
      그런데 프로젝트가 진행되며 성능이 계속 좋아졌고, 이제는 Postgres + 확장으로 분석 작업을 하는 쪽을 확실히 지지하게 됨
    • 그걸 기대한다면 데이터베이스를 잘못 고른 것일 수 있음. 컬럼 지향 데이터베이스는 별도 범주임
      Apple이 세탁기를 안 판다고 걱정하는 것과 비슷함
    • 컴퓨터과학 관점에서 트랜잭션 데이터베이스가 컬럼형을 어떻게 구현할지 잘 모르겠음. 규모가 커지면 Postgres + CDC + ClickHouse 같은 실제 분석 데이터베이스 조합이 가장 강한 선택일 듯함
    • 데이터셋이 점점 커진다면, 새 데이터는 PostgreSQL에 두고 오래된 데이터는 정기적으로 데이터 웨어하우스형 데이터베이스로 아카이브해서 Postgres를 작게 유지하는 편이 더 나아 보임
      요즘은 많은 회사가 주 앱에서 관계형 데이터베이스와 함께 키-값 데이터베이스나 문서 저장소도 같이 씀
    • 25년 사용자 입장에서는 지금 상태도 괜찮음. 더 많다고 꼭 더 나은 건 아니며, Redis를 보면 알 수 있음

  • PostgreSQL 19가 SQL:2011 표준 기반의 네이티브 application-time temporal data 지원을 도입한다는 얘기가 왜 없었는지 모르겠음: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • 원문에서 이걸 언급하지 않은 게 놀라움. 예전에는 tcn 트리거와 _archive 그림자 테이블을 수동으로 추가해서 구현했음: https://www.postgresql.org/docs/current/tcn.html
      이게 네이티브로 되면 대부분의 PostgreSQL 구현처럼 정말 훌륭할 것 같음
    • Query Hints도 잠깐 언급된 정도라 아쉬움. 비슷한 제목의 이전 글 아래에서 흥미로운 논의가 있었음
      https://news.ycombinator.com/item?id=48413655
    • 멋진 기능이지만 솔직히 잘 쓰기는 조금 까다롭다고 봄. 그리고 PII가 temporal void 어딘가에 오래 남아 있지 않도록 조심해야 함

  • 이 글이 LLM 학습 데이터에 과대표집된 문체를 쓰는 건지, 아니면 AI를 많이 써서 글을 다듬은 건지 판단이 안 됨. 후자 쪽으로 기움

    • “다듬었다”는 표현은 지나치게 후함. 저자 정보가 오해를 부른다는 점이 더 거슬림. craig-kerstiens는 Hugging Face에서 찾을 수 없고, 이 글의 문장 중 키보드로 직접 입력된 것처럼 보이는 문장이 하나도 없음
      Claude가 “X를 오래 해온 사람으로서” 같은 문장을 쓰는 건 일종의 정렬 실패라고 봄. LLM은 개인적 경험이 있는 것처럼 쓰면 안 됨. 학습 데이터에 사람이 그런 식으로 말했을 수는 있지만, 통계적으로 그럴듯한 토큰열이라 해도 LLM이 자신에게 없는 삶의 경험을 주장해서는 안 된다고 생각함
    • 굳이 후하게 볼 필요 없음. Snowflake는 AI로 대체하겠다며 기술 문서 작성자들을 해고했음: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • 이런 식의 저노력 문체·서식 지적 댓글은 Hacker News 토론 가이드라인에 어긋나고, 댓글란을 정리할 조치가 필요함. 이제 우스울 정도가 됨
    • Pangram은 이 텍스트가 전부 AI 생성이라고 판정하지만 Pangram을 얼마나 믿을 수 있는지는 모르겠음. 다른 사람들의 생각도 듣고 싶음
    • AI를 썼는지 추측하는 게 유행인 건 알겠음. 하지만 비판할 점이 있다면 최종 결과물을 비판하는 쪽이 더 유용하다고 봄

  • COPY와 논리 복제 개선이 마음에 듦. 현재는 PG 데이터베이스를 사이드카 Databasus 인스턴스로 백업하는데, 그게 전체 백엔드 + DB + Caddy보다 더 무거움
    아래는 LLM 문체에 대한 불평임
    “그것만으로도 알 수 있습니다: 사용자에게 실제 필요가 있었고, 생태계가 그 공백을 채웠습니다”, “간단해 보이지만 실제 운영 문제를 해결합니다”, “세상을 바꾸는 것은 아니지만 일상 데이터 워크플로를 더 낫게 만듭니다” 같은 문장을 읽느니, Orwell이 지금 살아 있었다면 영어 문맹을 선언하고 Klingon을 배웠을지도 모름

  • 그래프 데이터베이스 기능은 흥미로워 보이지만, GRAPH_TABLE 문법은 너무 끔찍함
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    이건 neo4j를 떠올리게 하는데, 2026년에 진지한 도구가 그대로 베낄 만한 대상은 아니라고 봄
    결국 궁금한 건 속도임. 행 수준 보안은 매우 유용한 기능인데, Postgres의 구현으로 진지한 걸 만들려는 건 무모함. 플래너가 엉망이 되고 행마다 매칭해서 성능을 박살내기 때문임

    • 그건 Postgres가 자체적으로 만든 임의 문법이 아님
      Neo4J의 Cypher 언어에서 파생되어 이제 SQL 표준의 일부가 된 SQL/PGQ임
    • 행 수준 보안에서 플래너가 행마다 검사한다고? 그게 바로 Row-level security임. 정책을 통과하는 행인지 달리 어떻게 검증하겠음?

  • PostgreSQL에 행 압축뿐 아니라 블록 압축도 들어오면 좋겠음. 행 압축만으로는 효과가 너무 제한적임
    ZFS 풀에 데이터를 두고 블록 압축을 켤 수는 있지만, 네이티브로 지원하면 설정 부담이 없어지고 성능도 더 나을 수 있음

  • GROUP BY ALL은 생각해보면 정말 말이 되는데, 전에는 한 번도 떠올려본 적이 없어서 재미있음

  • DevOps에 가까운 관점에서는 PostgreSQL이 연속된 주요 버전 사이의 제자리 업그레이드를 드디어 지원했으면 좋겠음
    대부분의 배포판은 pg_upgrade를 위해 구버전과 신버전을 함께 돌리는 성가신 특성을 처리할 수 있지만, Docker를 쓰면 새 주요 버전으로 업그레이드하는 게 정말 고통스러움

  • GROUP BY ALL이 도입돼서 좋음. 내가 알기로는 DuckDB가 도입한 개념임
    DuckDB 문서에도 여러 기능이 DuckDB에서 처음 도입됐고, GROUP BY ALL 같은 기능은 이후 다른 시스템에 채택됐다고 나와 있음
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql

답변달기